In my main thread I create an OpenGL context and draw some figures on it and it works well. I want to modify the same OpenGl context in another thread. To do this I passed the HGLRC of main thread to second thread and tried to modify this context but the SwapBuffers method was always unsuccessful. Does anyone know how to work out this problem?
Cheers
I think one context per thread is the way to go. I’m not sure if the render context id from one thread makes sense if used in another. I could be wrong of course -
In any case, you only really need to be using threads if you have significant `other’ processing to do - such as your own transform and lighting, or AI (or in my case, infra-red thermographic imaging) - at the very least, I think you may have to sync with the thread, calling swap-buffers in the thread that originally created the render context.
Hi
I think u must have different rendering contexts for different threads. Then share the info using
wglShareLists(HGLRC1,HGLRC2);
Thats nice to do
Yes - but that allows the sharing of resources that may be used by more than one thread, within more than one context - rather than running two threads and them both having the same context. I don’t think you are allowed to use one thread to write to another threads context.
ShareLists shares display lists and texture objects. I think the solution to your problem would be simply to establish a communication between your 2 threads. I think a pipe is used for this.
Also, wouldn’t it be better to create a thread from your main thread and run opengl inside that one? Im wondering how to separate my rendering code from my user interface code myself.
V-man
Well I have a main thread ( the main window ) and a secondary thread which creates its own window and render context. Its threadmain' is obviously the render loop. At the moment, they are sync'd by sending messages to each others message loops - this is not ideal but it does mean I don't have to worry about blocking\semaphores etc. The secondary thread executes asleep’ each iteration because from my experience, the gl drivers running at kernel level (or thereabouts) tend to eat up 100% cpu time and make the ui sluggish - even when I put the secondary thread on a lower priority (the thread may be on a lower priority, but most of the time is spent in the drivers, which are a very high priority).
Anyway - its worth a try for you I guess.
Well, perhaps you should also have a look to:
GLFW -> http://hem.passagen.se/opengl/glfw/ 
nice multithread support for many platforms.
[This message has been edited by Ozzy (edited 04-03-2002).]
You should always have a sleep in your render thread, sleeping is the only controllable way of allowing other threads processor time. You should use queryperformancecounter to calculate how much time your render loop has taken to execute, and if it finished quicker than you’re allocating, sleep for the remaining time.
For example, if you wish to fix your frame rate at 60hz, and a single pass through your render loop took, say, 10 milliseconds, then you would sleep for 6 milliseconds (1000/60 = 16.xxxx, 16-10=6).
As for GL in threads, well, a gl context is invalid to the parent of the thread that creates it, so I don’t believe its possible to share gl resources between parent threads - only between contexts created in the same thread, or child threads (hint: create your contexts in one thread, share resources between those contexts, and then create child threads to handle rendering, because the contexts will be valid for those child threads - so long as you synch your makecurrents).