I actually already fixed the old code so that it should work as it was intended now (the original code was actually just a bit broken), and this extra Cocoa stuff isn't needed. In my tests it now works fine and the CPU drops slightly while keeping the frame rate fairly constant.
Like I said, I wouldn't want to change the existing behaviour so that the frame rate becomes slow while the window's still on-screen, but maybe it's something that could be added as an opt-in.
We’re seeing this intermittently on Mac OS 10.11+. The plugin window is occluded & in the background for awhile, and somewhat randomly, the framerate will jump up an order of magnitude in some cases (e.g. 60 Hz -> 500 Hz, but more commonly something ~150 Hz). It seems to occur differently, if at all, on different machines (one 13" retina MBP seems to be the worst).
It looks like the code to prevent the overdrive was moved to swapBuffers, and I’m not really sure how it’s failing. Any chance we could have a way to query that occlusionState (if it exists) so that we can do some custom handling? We’d love a way to drop the framerate significantly when its occluded without having to rely on timing the frames.
Hmm, the code in there to prevent this situation looks OK to me… What have you got the swap interval time set to?
We’re not explicitly setting the swap interval, so it’s just 1. As I mentioned above it does seem worse on certain machines — perhaps ones that use Intel integrated graphics? Hard for us to tell exactly though.
The recommended way to drive OpenGL rendering loops on macOS is with CVDisplayLink.
On SR’s branch CVDisplayLink is used and this solved similar performance problems for us as well as other problems.
(Note that the branch didn’t keep up to date with JUCE 5 but I hope the relevant code didn’t change too much…)
You can try to see if this helps. Cheers, Yair
Thanks for the response. We’d love a CVDisplayLink-driven loop (it’s definitely what we’re most used to), but thus far have wanted to stay on the official Juce branch.
This is happening for me too.
I haven’t set the swap interval either.
Just checking in on this again. To avoid this problem, we’ve had to turn off continuous repainting, which means our message thread is always locked during openGL render calls. While not terrible for a single plugin UI, this seems to really start to drag performance down when multiple plugin UI’s are open.
Did you use a thread/HighResTimer + AsyncUpdater to call the context->triggerRepaint ?
Sorry that answering this thread is taking so long. But we cannot possibly see what could be wrong with the extra throttling code when the window is occluded.
Can you set a breakpoint at juce_OpenGL_osx.h:179 and check why the sleep there is not kicking in?
I’m seeing this same problem for an OpenGL project I’m working on. I verified this issue is happening also in the DemoRunner OpenGLDemo.h on the latest JUCE 7.0.3 running on my macbook M1 air with Mac OS 12.6.
The CPU suddenly goes up when I hide the DemoRunner window and when I bring it back up front, the CPU drops.
From reading the posts in this forum topic, I conclude that JUCE has already tried to include a fix. Has there been any changes recently in the juce OpenGL code related to this that might have introduced the problem again? Hopefully this issue can be fixed soon.
A fix for this issue is now available on develop:
