Quote Originally Posted by wysota View Post
I'm sure this is going to backfire sooner or later. For example when you need to handle some input events in the widget.
Well, I've reimplemented the mousedown/up/move events, keypress, and the GL drawing/resize/init events in this separate thread on this QGLWidget with a null parent (they're parsed by the thread->exec() loop). I have a separate MainWindow with many other widgets in the primary UI thread handling mouse events and such on QPushButtons and other QGLWidgets.

But when I have to upload about 14 640x480 textures at 60Hz, do rotation/translation/scaling of these polygon mapped textures, and then swapbuffers, these operations begin pushing the 16ms interval that I have at 60Hz monitor refresh rate. Doing much of anything else in that thread (rendering other windows) could prevent this from being achieved.

And I'm pretty sure that most OpenGL calls block until completed. It wouldn't make sense for the pipeline otherwise to have some blocking and some non-blocking. The moment you called another blocking call after several non-blocking calls, the pipeline would have to block until the previous commands had been completed. But I might be wrong on this one. GPUs are highly parallel within the individual openGL calls (i.e. texture mapping and projection calculation), but they're serial in their execution of those calls.


Render to a context - yes. But nothing more. QGLWidget is still a QWidget which is not thread-safe and you can't do anything about it.
I think this is why the documentation says you need to intercept and prevent the draw/resize events in the main UI thread if you're going to draw from another thread.