I am writing an OpenGL audio visualizer and using the
OpenGLRenderer to have a separate render thread for OpenGL. Just as shown in
OpenGLDemo.h in the JUCE demos, I want to have my OpenGL rendering scaled to fit the
OpenGLDemo.h, in the
OpenGLRenderer::renderOpenGL() method it uses the following code to set the OpenGL viewport to match the component size:
auto desktopScale = (float) openGLContext.getRenderingScale(); ... glViewport (0, 0, roundToInt (desktopScale * (float) getWidth()), roundToInt (desktopScale * (float) getHeight()));
Is this a race condition between the JUCE Message Thread and the OpenGL rendering thread on the
Component width and height data?
From what I understand, the JUCE Message thread handles things like Component resizing, mouse clicks, etc. The OpenGL thread accesses the Component width and height (in the last line of code above), and since the Message thread could simultaneously be writing to the Component size while the OpenGL thread reads from it, I believe this is a race condition.
If I am correct in my thinking that this is a race condition, what is a good way to deal with this race condition? I thought about locking the OpenGL thread while the Component is being resized and then unlocking after resize has completed. Is asynchronous messaging a better solution? Maybe an atomic boolean flag?
I would assume other people have dealt with this issue and was looking to see if there was a standard solution most people used.