I’ve nearly finished my ActiveX control, which uses OpenGL. Its an in-process control and spins off a thread for each instance to do all of the drawing, swap buffers, etc.
I haven’t mutexed any of the rendering code at all (and I have no global variables) and it all works nicely - even when I embed four of the little buggers on a web-page. Now call me a stick in a bucket of pig poo, but I think it should fail - unless of course the driver writers have been clever and mutexed\semaphored OpenGL calls for me?
I don’t know. I’m not complaining, I’d just like to know if OpenGL multi-threading behaviour is documented anywhere or if you can tell me what the `rules’ are.
You might want to state exactly what you are concerned about. The rules with GL are that a context may only be current on a single thread at a time. (There are also some rules about shared objects, but I don’t remember off the top of my head)
To be clearer, each instance of the control creates a single context but because its an in-process control, all instances of the control execute within the same program .exe. Each instance of the control creates a window\render context for itself. I can’t use global variables however (such as a global state object) because of the controls `in-processness’ - which is why I’m confused about the drivers working correctly.
I guess I’ve done it correctly because it works ok. I’m just not sure why!
It works because you “each instance of the control creates a single context”. That is kewl. As long as a single thread is assigned its own context and you dont try to call an OpenGL function from one thread on a context of another thread you should be ok. Sounds like a pretty neat little piece of code to me
