I have a quick question. I have a plug-in project with various visualization of audio capabilities which uses the OpenGLRenderer class and direct calls to OpenGL API. Doing so allowed me in the context of a desktop app to reduce in a fair amount the CPU load involved in the display, in comparison with other approaches using the software renderer / CoreGraphics only, or the JUCE OpenGL wrapping made by simply attaching an OpenGL JUCE context to the main component.
However, when I ported the same exact code from a desktop app to a plug-in, to be executed in a PluginEditor class, the CPU load gains of my approach weren’t good anymore, for example in Reaper on Windows 8.1 and even more on Reaper + macOS 10.10.
So as a quick solution to that new issue, I would like to find the best way to reduce the default FPS put at 60 Hz when using the setContinousRepaint. Someone already did that ?
I have tried different things without the expected CPU load decrease on the two situations (Reaper Win 8.1 + Reaper macOS 10.10) :
Changing the value of the SwapInterval with ContinuousTime does almost nothing in my tests
Keeping the ContinuousTime behaviour but adding some calls to Thread::Sleep so I execute at a given rate the rendering (works well on Windows but actually increase the CPU load on macOS 10.10)
Removing the ContinuousTime behaviour, and calling the function triggerRepaint inside an AsyncUpdater, called by the timerCallback of a HiResTimer class. It’s still good on Windows, but even worse than the last case on macOS 10.10
Someone had already this issue ? And had found a good solution ?
No the whole rendering is done using the OpenGL API. For now I just want to know if people have found efficient ways to reduce the FPS in order to reduce the CPU load in similar contexts.
When I have some time, I’ll prepare a sample project showing my issues for desktop apps + plug-ins using the same rendering code, so you will be able to compile a simple example and see by yourself the issues I’m talking about.
using OpenGL here, but not Juce, so I’m not sure how helpful this is going to be, but the approach I use is to call invalidate() when something has changed in the UI, then let the OS schedule paint calls.
There is also a timer running in the UI thread that calls a refresh() callback on the UI to poll for changes at roughly the desired FPS. With this scheme the CPU usage stays very reasonable.
The downside is that you have to adjust timings to compensate for non-steady drawing intervals (jitter).
Also in OpenGL the swap Interval is just a way to toggle VSync on and off mostly, to prevent tearing. In my experience it has very little effect on performance - and there’s no reason it should either I believe.