Multi-threaded GUI possible?

[Gus Lott]

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.

[wysota]

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.

I would say exactly the opposite, it makes perfect sense for some calls to by asynchronous and some to be synchronous. Consider the following example pseudocode:

glBegin(...);
glVertex(x1);
glVertex(x2);
glVertex(x3);
glEnd();

glBegin(...);
glVertex(x1);
glVertex(x2);
glVertex(x3);
glEnd();

To copy to clipboard, switch view to plain text mode 

It makes perfect sense to make glVertex calls asynchronous as it makes no sense to transfer data to the graphics card vertex by vertex as you'd be just wasting bandwidth and time. It makes perfect sense to synchronize the context not earlier than the glEnd() call.

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.

That's exactly the point Why block at every command if you can only block at the last one? What if there is a context switch somewhere inbetween? What to do with the data already pushed to the pipeline?

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.

That's not enough. You can only touch the gl context which is independent of the gl widget but you can't touch the widget itself (i.e. change its geometry) from another thread hence you can't simply push the gl widget to another thread. While it might work in some cases it is bound to fail eventually.

Again, my opinion is you don't need multiple threads to do multi-gpu rendering (of different contexts) and using multiple threads won't make your application do multi-gpu rendering automatically.

[Gus Lott]

I know that that begin/end code actually uploads each vertex at a time (synchronously with all the function entry overhead with each vertex). There's a "glVertex3fv()" call that uploads vertices from an array in memory much more efficiently outside begin/end. Begin and End are not even part of the OpenGL ES subset because of how inefficient individual vertex calls are.

The linear algebra, projections, and vertex culling are done at the swapBuffer call when you're done, I believe. But all the data uploading is synchronous and can take a considerable amount of time.