[Qt-interest] Qt4.4.3 paintEvent thread-safe

[Oliver.Knoll at comit.ch]

Prasanta Sadhukhan wrote on Monday, December 22, 2008 10:14 AM:

> Hi,
>
> I want to know if is it alright to introduce mutex lock/unlock inside
> a widget PaintEvent function?

You should not need this, see below.

> But, one problem after I introduced this lock, is one of our
> benchmark test is running 4 times slower (90secs compared to 22secs
> without lock/unlock). Can anyone shed some light?

Aquiring a lock is *expensive*, so doing this in a paint method (which gets called dozens of times per second) degrades your performance considerably (I wouldn't have expected an impact of 90s vs 22s though...).

So the question is: from which thread are you calling your paint method? If it is any other thread than the *GUI thread* (aka "main" thread), then the answer is: don't do this! ;)

Painting/widget modification in Qt is *not* thread-safe (one reason being performance), so you are only allowed to call them from within the GUI thread (the thread which originates from your main() function).

So the typical solution: if you have any other worker threads, make them signal that some work is done and ready to be displayed. Use "queued connections" (http://doc.trolltech.com/4.4/qt.html#ConnectionType-enum) as to synchronise your (worker) threads with the GUI thread.

Then when your widget receives the signal in the corresponding slot ("updateGui" or whatever) it is safe to paint without any mutex locking.

This is a typical question which pops up in regular intervals here on qt-interest at trolltech.com, so you might also want to consult the archive (http://lists.trolltech.com/qt-interest/) / google.


Cheers, Oliver