[Qt-interest] Handling mouse events in soft-realtime case

[Hostile Fork]

>> On Fri, Jul 31, 2009 at 12:03 PM, Oliver
>> Demetz<forenbeitraege at oliverdemetz.de> wrote:
>>
>> Isn't there a possible way to always get mouse events via  a thread  
>> or
>> something?
>>
> From: Ender EREL <erelender at yahoo.com>
>
> Instead of handling mouse events in another thread, you could do the
> painting to a pixmap in another thread and when the painting is
> finished, copy that pixmap to the main thread and paint it there.

Since I've been trying this in a program I'm currently writing, I  
thought I'd throw in a couple of warnings.  I started from the  
Mandelbrot sample:

	http://doc.trolltech.com/4.2/threads-mandelbrot.html

I wish the QImage allocation in renderthread.cpp had linked to the  
following notice (or the sample description had called it out  
prominently somehow):

	http://doc.trolltech.com/4.4/threads.html#painting-in-threads

As it says, you can't use a QPixmap on a non-GUI thread...so you have  
to use QImage.

You also can't use any classes that use QPixmap in their  
implementation... including QCursor, QIcon, and QBitmap.  (It would be  
nice if those classes were mentioned explicitly in the warning for  
QNoobs like myself who don't have that derivation memorized.)    
Obviously any routines/classes of your own--or library routines--that  
use any of these classes cannot be called in a non-GUI thread either.

Also note that not all QFont or QFontMetrics are usable on non-GUI  
threads.  So if you're doing any QPainter::drawText calls then check  
QFontDatabase::supportsThreadedFontRendering ...

Other than that, it *seems* like there's a guarantee that you can use  
the other QPainter functions on a QImage in a non-GUI thread.   
Everything else I've tried has worked without generating any warnings.

BUT if your paint routine is already pretty fast, this doesn't do much  
for ensuring you don't drop ANY mouse messages.  Drawing the QImage  
will still tie up the GUI thread for some amount of time.  You can  
time the paintEvent in the Mandelbrot sample for a data point on what  
that delay is like.

Regards,
    Brian

http://hostilefork.com