QWindow on a non-GUI thread

SGaist

Hi,

IIRC, you can move your QOpenGLContext to a different thread but not the QWindow.

rtavakko

@SGaist Thanks for replying.

Are you aware of any alternatives to QWindow where using a thread is possible?

I do most of my rendering on a QOffscreenSurface subclass and the QWindow is only displaying the result. But since it sits on the GUI thread, any events there cause it to drop frames and stall.

SGaist

Maybe the QQuickRenderControl example might help.

rtavakko

@SGaist Thanks! I will play around with that example

rtavakko

I'm still stuck on this.

Anyone know if there is a way to use a QOpenGLContext and other QT OpenGL resources with a native window?

QSurface seems to fit this purpose and it seems to be compatible with non-GUI thread use. I'm assuming I have to implement window resizing and visibility but I'm not sure where to start with that. If anyone's played around with that concept, do you have any tips or advice on getting started?

rtavakko

An update on this mainly based on the results of this thread (links to example projects are in this thread):
https://forum.qt.io/topic/125267/wgl-window-on-non-gui-thread

To summarize things, the real issue here is using QT's OpenGL classes to render into a QWindow or similar class. Because QWindow can only live in the GUI thread, projects that have more complex UI and a lot of widgets, will have a hard time with high resolution and high framerate OpenGL rendering.

There are two options at this time to have decent OpenGL performance while also using QT's UI:

1 - Using QT's OpenGL classes and UI while optimizing UI widgets:

This is the concept that QT is currently designed around and what everyone will recommend. Basically what I personally had to do was to use QT's concurrent programming options. The easiest example:

QtConcurrent::run([=](){
//Code that is currently causing your UI to block
});

While this option works and makes sense, it complicates things. You obviously cannot make UI calls in the threaded block of code and also there is the limitation of not having any control over existing QT implementations. For example, if a certain widget is by default performance-intensive, you are stuck with a performance hit.

2 - Using QT's UI with non-QT OpenGL classes:

The only option for rendering into an OpenGL window on a non-GUI thread is to get away completely from QT OpenGL classes and use a library like GLFW.

I know people on this forum tend to immediately shut down the idea of a window on a non-GUI thread, but this seems to be the best way for complex projects using OpenGL.

3 (Not possible currently) - Using QT's UI with QT OpenGL classes, along with a QWindow-type class that can actually live in a non-GUI thread:

This would be heaven. The concept of a QOffscreenSurface being able to render on a non-GUI thread but not being able to do the same for QWindow really makes no sense. I understand that this is done to allow for events to be delivered to a QWindow but it would make sense to create some flexibility for programmers to take care of resizing and visibility themselves since this is perfectly doable with OpenGL.

SGaist

Hi,

For internal design and discussions about the OpenGL stack you should go to the interest mailing list. You'll find there Qt's developers/maintainers, this forum is more user oriented.

rtavakko

@SGaist Thanks, I will do that. I wanted to also share my experience to best use QT's existing OpenGL and UI features.

wrosecrans

@rtavakko said in QWindow on a non-GUI thread:

QT OpenGL resources with a native window?

Most of the Qt OpenGL helper functions should actually "just work." They use whatever is the "current" OpenGL context. You just can't touch the GUI stuff. Something QOpenGLShaderProgram will have no idea if you are ultimately going to be rendering to a window or an offscreen surface.

That said, I ultimately gave up trying to do multithreaded OpenGL with Qt. Between the Qt limitations, and the GL language-lawyering about what exactly is an "object" that will be shared between different contexts, etc. If you do try to do multithreaded OpenGL, you'll probably be much better off with an offscreen rendering thread and just drawing the most current completed FBO in the GUI window.

You may want to pick up Vulkan if you really want to go down the rabbit hole of multithreaded drawing. It's a much more modern design, with much more explicit state that can be coordinated between threads and concurrent operations explicitly. (But it is a pain in the ass to do all of that. There's no "easy" GPU drawing in parallel.)

rtavakko

@wrosecrans

Yes, I'm rendering using a QOffscreenSurface on a separate thread then displaying the frame on a QWindow on the GUI thread, but it makes sense to have all of the video rendering on the same thread so we're not interfering with the GUI thread.

I've successfully tested this concept with GLFW-based OpenGL windows and QT UI. I doubt Vulkan will be any different since from what I understand the render window will still need to sit on the GUI thread.