In a JUCE 7.0.5 standalone application, we have observed different behavior of
OpenGLContext::setContinuousRepaint on macOS and Windows.
We have an
OpenGLContext attached to an
OpenGLRenderer to render custom OpenGL components and also attached to the main
Component of the app so all JUCE UI is rendered using OpenGL. When
OpenGLContext::setContinuousRepaint(false) we get two different behaviors on macOS vs Windows:
macOS : Our implementation of
OpenGLRenderer::renderOpenGL() is NOT called continuously. It only gets called occasionally when mousing over and interacting with the UI.
Windows : Our implementation of
OpenGLRenderer::renderOpenGL() is called continuously.
The macOS behavior is what I was expecting to see on Windows. When you call
setContinuousRepaint(false) I would expect
renderOpenGL() to not be called continuously.
Is this a bug in JUCE for Windows?
Has anyone else observed this?
Another interesting observation on Windows: when we set
OpenGLRenderer::renderOpenGL() was continuously called, it seems our JUCE UI components were NOT being continuously repainted by OpenGL. We actually saw a noticeable CPU/GPU performance improvement with
setContinuousRepaint(false) on Windows, while still being able to see all of our OpenGL components moving at a normal frame rate. I believe this performance improvement was due to JUCE UI not being continuously repainted by OpenGL.
It would be nice if we could call
setContinuousRepaint() on either platform and only have it affect the rendering of OpenGL components (
OpenGLRenderer::renderOpenGL()), while JUCE UI components would only be redrawn when needed (e.g. mouse over) and JUCE UI components would never continuously redraw themselves with OpenGL regardless of setting
I may be wrong about this last claim as I did not check breakpoints for the JUCE UI rendering, but this looked like what I was observing.
If I change the OpenGLDemo to disable continuous repainting and then run it on Windows 10 + Nvidia GT1030, I don’t see renderOpenGL being called continuously - it only gets called when something triggers a repaint of a non-opaque component in the context.
First, make sure you’re testing on the develop branch. Then, it would be helpful to know what behaviour you see in the OpenGLDemo if you disable continuous repainting. Is it the same as your app?
If the app + demo behave in the same way, then the behaviour might be due to something specific to your system. In that case, it would be good to know what Windows versions and hardware you’ve tested. It’s definitely worth testing a few different Windows devices.
If the app + demo behave differently, then there’s probably some difference in configuration between the app and the demo. You can try inspecting the demo code to see how the GL context is set up.
Thank you for the info! I’ll test against the OpenGLDemo & develop branch and report back here with specs if I find concrete confirmation of an issue.
Now that you mention non-opaque components, I could see this issue being related to our own non-use of
Component::setOpaque() in our JUCE component hierarchy. I think the majority of our app (including the MainComponent) does not set
Component::setOpaque(true) (I am planning to add this to our code). If non-use of
Component::setOpaque() is the problem, it still surprises me that we saw different results between OSes, but maybe there is some macOS-specific optimization related to this.
Regardless, I will look deeper into our issue and report if I find something significant. Thank you again for your feedback and tips!