It would be very nice if instead of just being able to make current context active, it would also remember what context was active before and when you make it inactive again, the old context is automatically made active again.
I had some massive problems because JUCE works not this way and I’m using more than one OpenGLComponent and more than one threads that concurrently access the OpenGL contexts to upload textures to them.
Basically, with the way JUCE works now at the moment, without adding extra features, I could not find a way to get it to work. I know that uploading textures while drawing is a very special case though.
Also, does setVisible() not work for OpenGL components?
[quote=“zamrate”]It would be very nice if instead of just being able to make current context active, it would also remember what context was active before and when you make it inactive again, the old context is automatically made active again.
I had some massive problems because JUCE works not this way and I’m using more than one OpenGLComponent and more than one threads that concurrently access the OpenGL contexts to upload textures to them.[/quote]
I don’t think this should be set as the default behavior,
it should be easy to keep a stack of active contexts for each thread, isn’t it ?
You’d need a ScopedOpenGLContextSetter class. Probably do-able. But can’t you just set the context to current before each drawing pass? It does check whether it’s already the current context, so it shouldn’t waste any more time in the grand scheme of things.
If no context was created, it seems that at least on Windows, this function should not be called from a Thread different than the GUI Thread, otherwise nothing works as expected.
Maybe one could change this function in a way that it is Thread-safe, by using callFunctionOnMessageThread() inside? I think that might be the best way to get around the problem…
You mean if you try to draw from a different thread than you created the context on? It should be OK on Windows as long as you always make the context inactive after each draw, and don’t draw from different threads at the same time.
I have code that creates an OpenGL context on a thread in Linux, and on Mac it’s not a huge problem (as long as you only render from one thread), but it’s sounding like this is a common problem.
Maybe OpenGL contexts need a redesign to cope with the threading limitations? I can throw in my Linux code, but it’s a copy/paste job from the juce platform specific code with lots of #ifdefs.
