I would assume(and I may be incorrect) that qt assumes any openGl to the GUI thread. This means that even if you try to create it in a new thread or move it to one, it will be forced back to the GUI thread. But like i said i am not certain of this

I don’t know the answer.

Just out of curiousity what is the use-case for this? What version of OpenGL are you using? What is your target hardware?

If you are attempting to multi-thread in order to save on GUI thread processing (keep in mind I don’t know the internals of Qt) on a platform with dedicated graphics hardware wouldn’t the processing be pushed off of the GUI thread by default?

OpenGL, particularly the recent versions, attempts to push just about everything to the graphics hardware via shaders. In the latest versions there is no fixed-function state on the client-side at all.

All that being said if your goal is not to increase performance my answer of I don’t know still stands. Sorry if this post doesn’t really help you.

Hi,

Hornsj2 wrote:

I don’t know the answer.
Just out of curiousity what is the use-case for this? What version of OpenGL are you using? What is your target hardware?

Hornsj2 wrote:

I don’t know the answer.If you are attempting to multi-thread in order to save on GUI thread processing (keep in mind I don’t know the internals of Qt) on a platform with dedicated graphics hardware wouldn’t the processing be pushed off of the GUI thread by default?

@+

The issue is the fact that the rendering will(more than likely, but depends upon exactly what you intend to do) take place on a widget. Any widget, or subsequent class, will force any thread created to be thunked back to the GUI thread. Generally it seems to be good practice to keep threads for computational use only.

I’m agree with you :

• Creating a OpenGL texture is computational
• Creating OpenGL VBO is computational
• Crating OpenGL list is computational

Then the rendering of all these OpenGL objects are done in the GUI thread.

I could be wrong but I believe the simple act of calling OpenGL functions to create data structures passes the data to the OpenGL context (server).

OpenGL is pretty much a state machine so if you are setting up the state in a context to perform rendering and then copying that state between contexts to save processing time I’m not sure if you will see a performance gain.

If you can achieve this and measure the results I would be interested to see what they are in terms of performance.

Hornsj2 wrote:

I could be wrong but I believe the simple act of calling OpenGL functions to create data structures passes the data to the OpenGL context (server).

OpenGL is pretty much a state machine so if you are setting up the state in a context to perform rendering and then copying that state between contexts to save processing time I’m not sure if you will see a performance gain.

If you can achieve this and measure the results I would be interested to see what they are in terms of performance.

True. The function of an OpenGL context is to set the parameters under which a given scope uses OpenGL – comprised of components written by hardware manufacturers – runs. It also means you can use different versions, in different contexts in the same application.

The good news, sort of, is that different threads can use the same OpenGL contextr, but not at the same time. You’ll need to null the context in the thread that has it, then use a call such as the WGL call (windows only) ‘wglMakeCurrent’ to select the correct handles. The bad news is, it’s a pain in the butt to implement and slow if you do it wrong. You have to avoid switching unless you absolutely know you need to.

The generally accepted practice is to keep all your rendering in one thread, and use a message queue to execute OpenGL commands which are anomalous to the regular flow of your pipeline. If it’s good enough for the rest of us, it’s good enough for you :)

Thanks LiamMaru,
I have already try to use the same OpenGL context in different thread, but I have forgotten to call : QGlContext::doneCurrent() in the main GUI thread and I had some crash.
I will try it as soon as possible.

But, when using the same OpenGL context in another thread, it will not be possible to refresh the view of the main GUI thread… So it will freeze the application !

No issue ?