OpenGLContext drawing restrictions/threading


#1

I was wondering if anyone had some tips about using OpenGLContext and what is/is not allowed. Here's what I ran into:

I found that for a large component, doing just very simple drawing, that attaching an OpenGLContext to my component speeds drawing up dramatically. This is particularly true on a Retina MacBook Pro. This is not so surprising - there are a lot of pixels to push. I'm not making any OpenGL calls directly, just trying to use JUCE's OpenGL mode, and use JUCE's graphics calls.

Here's the problem: in a more complex component, I ran into crashes in OpenGL code and learned that OpenGL drawing appears to happen in a separate thread: without the OpenGLContext attached, my component's paint method gets called from the main message thread. With OpenGLContext, paint gets called from the OpenGL Rendering thread.

I originally had some code that modified an Image object in the mouseDrag callback method. I was getting a BitmapData object from the image, and modifying the pixels with my own code. This worked fine without OpenGL, but with OpenGL it would crash. Sometimes calling swapbuffers(), sometimes glDeleteTextures().

Once I realized the threading that was going on, I changed my image modification code to happen in the paint callback (thus, the OpenGL Rendering thread). This fixed the problem, but I'm wondering if there's something I'm missing.

Is there a recommended JUCE-appropriate approach for dealing with paint being called from a separate thread? I can arrange so the Image object is only ever accessed in the paint callback, but there are other data structures that need to be accessed from both mouse callbacks and paint. I thought I could use a CriticalSection to prevent mouse callbacks and paint from simultaneously accessing the same data structures, but is this the right appraoch for JUCE?

Sorry for the long explanation, but I wanted to be as clear as possible. Thanks in advance if anyone has some advice!