[Qt-interest] opengl thread

[Oliver.Knoll at comit.ch]

bert.ddecker wrote on Monday, January 18, 2010 11:28 PM:

> ...
> It is important that I render at a constant rate of 30 hertz, and by
> keeping my event loop and my rendering loop in a seperate threads,
> the rendering framerate will not drop when a lot of events are
> generated. 

Sorry, I did not answer the actual question: so you don't want to multithread the GL calls itself (which according to http://www.opengl.org/wiki/OpenGL_and_multithreading "Can I make GL calls?" does not improve things much anyway), but you want to have event handling in a different thread than the OpenGL painting.

As I said, you have to paint in the "main" thread - I believe this also applies to GL painting. That said, the actual Qt event loop (mouse events, keyboard events, socket reads, ...) is not so expensive (compared to the actual GL painting). But what could become expensive is the actual *handling* of those events.

And you can very well put this handling into a separate worker thread! And once this worker thread has calculated its data, you can send a queued signal (http://qt.nokia.com/doc/4.6/qt.html#ConnectionType-enum) to the main thread, as to signal that the new data is ready to be displayed (or whatever).


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