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

[Oliver.Knoll at comit.ch]

Prasanta.Sadhukhan at Sun.COM wrote on Monday, December 22, 2008 1:33 PM:

>> ...
>> 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.
>> ...
> And yes, I do all the paintings into offscreen surface in main thread
> [which executes main()] and relegated the flushing of "offscreen" to
> "screen" in paintEvent in the thread which created QApplication and
> executes exec().

So you indeed have the painting in a different thread than where the QApplication "lives", so I understand.

> I cannot creat QApplication/exec in "main" thread as
> the stack is designed in such a way [the main thread initialises all
> network, i/o, graphics etc, so all the graphics painting will be done
> in "main" thread].

What "stack"? Application stack? The call stack? ;)

It is quite unusual to have the QApplication::exec() run in a separate thread and do the painting in the main thread.

Why don't you put the initialisation (which I assume takes a long time: network IO etc.) into a separate thread (the "initialisation thread") and put the QApplication::exec() into the "main" thread, together with the painting?

In the end it doesn't really matter in which the QApplication::exec lives - as long as you paint (or update widgets, for that matter!) in the *same* thread! I am just saying that it is a bit weird to have the QApplication.exec() live in another thread than the "main" thread...

> You can get the idea from the attached qt app. As

Sorry, I can't debug other people's code.

> such, the above design of doing all the paintings into "offscreen"
> surface [QImage] and then sending update() back to exec() thread
> where paintEvent flushes the offscreen into QPainter screen is
> working and our testsuite also passed, except for this 1 benchmark
> which shows slowdown Can you tell me how can I modify the app to use
> queued connection? or maybe point to some example

You might want to have a look at the famous "Mandelbrot" example:

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

There you have exactly the situation where the compuation is done in a "worker" thread, and the widget/paint updates are signaled to the "GUI" thread (where the QApplication::exec() lives in), using "queued connections".


Cheers, Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22