OpenGL and thread sensitivity
Author
Due to a rather annoyingly long period of trial and error i found that OpenGL commands only work within the thread that the OpenGL context is created with (as with OpenAL). Can anyone explain how this actually works, and if there is a method and changing the thread the OpenGL context works with? It would be handy to not have to recreate the context and have to reload every damn texture and shader...
zppz is right about the function to look up. You have to release the context from one thread before you can obtain it in another, so be carefull about that.
The 'how' of it working is down to how Windows provides handles and assigns contexts internally.
Why do you need to do this anyways?
The 'how' of it working is down to how Windows provides handles and assigns contexts internally.
Why do you need to do this anyways?
Author
_the_phantom_:
The primary reason for this was to have the windows messages on a seperate thread from rendering (because i was using WM_... for input etc), and i found that you can only listen for messages on the same thread the window was created. But then other things led me to try and think around the threads in other ways...
thanks for the help, and yeah i read the wgl functions in the MSDN, but if i release the context im going to lose all my textures and whatnot because they are context sensitive, right? doesnt matter too much im just gonna have to plan everything else a little more carefully.
The primary reason for this was to have the windows messages on a seperate thread from rendering (because i was using WM_... for input etc), and i found that you can only listen for messages on the same thread the window was created. But then other things led me to try and think around the threads in other ways...
thanks for the help, and yeah i read the wgl functions in the MSDN, but if i release the context im going to lose all my textures and whatnot because they are context sensitive, right? doesnt matter too much im just gonna have to plan everything else a little more carefully.
you will only lose the texture infomation if you delete the context, if you just release it from the current thread then the context will remain, just unattached to a thread.
Anyways, the simplest way around your problem is to just keep the rendering in one thread (create the context in this) and handle the window messages in another and then pass them to the rendering thread in some manner.
Anyways, the simplest way around your problem is to just keep the rendering in one thread (create the context in this) and handle the window messages in another and then pass them to the rendering thread in some manner.
Author
Cool thanks for the help. Another reason was for having a threaded loading screen - while still loading OpenGL resources :(
But yea i noticed that wglShareLists also shares textures and shaders and whatnot for PBuffers (despite MSDN just saying display lists), so i assume thats the same for window contexts and not just PBuffer contexts?
But yea i noticed that wglShareLists also shares textures and shaders and whatnot for PBuffers (despite MSDN just saying display lists), so i assume thats the same for window contexts and not just PBuffer contexts?
yeah, its the same, the entry for wglShareLists() was probably written against the 1.0 spec or something daft, later extensions can add themselves to the list of things to share (it seems to share all OpenGL generated buffers)
Quote:Original post by Exorcist
_the_phantom_:
The primary reason for this was to have the windows messages on a seperate thread from rendering (because i was using WM_... for input etc), and i found that you can only listen for messages on the same thread the window was created. But then other things led me to try and think around the threads in other ways...
When you pump messages do this:
while( GetMessage(&msg,NULL,...) ) { Translate, Dispatch .. )
It will get the messages to all the windows, even the one in your thread.
I use a queue when I get input I push it into the queue and on every frame start
I look in the queue for input messages etc.
[Edited by - Name_Unknown on July 21, 2005 1:28:07 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
