[Qt-interest] opengl thread

Oliver.Knoll at comit.ch Oliver.Knoll at comit.ch
Wed Jan 20 14:19:56 CET 2010


bert.ddecker wrote on Wednesday, January 20, 2010 12:18 PM:

> Thanks a lot for your answer, it was very useful !
> Too bad qt doesn't allow me to have a seperate rendering thread and
> gui thread, 

Well, it does, kind of: with the only restriction that the "rendering" has to be done in the "main" thread. But everything else can be done in different threads, in as many as you wish!

(And I don't see why you would want to put the "rendering" into any other thread than the "GUI" (aka "main") thread. After all, "rendering" is all about updating the UI.)

Note that from a performance point of view it does not matter whether you trigger your GL commands from the "main" or any other thread - in the end they all are queued in the GL command queue and sent to the single graphic card anyway. So you would gain absolutely nothing (performancewise) by putting your "rendering" into a separate thread (left alone that Qt does not support that).

> than I wouldn't have to make sure all my events were
> handled in a very short amount of time. But I guess most of my events
> are handled in a very short amount of time anyway.

So I don't see why you want to separate this anyway! If your events are handled quickly, so where is the bottleneck? Just make sure the Qt event queue does not get blocked for too long by some heavy computation, and you should be fine.

And if it does take some time, then just put it (the event *handling*) into a separate worker thread, as done in the "Mandelbrot" example posted previously.


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



More information about the Qt-interest-old mailing list