Low FPS with OpenGL rendering in audio plug-ins

Audio Plugins
#1

Hello everybody !

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 ?

Thanks in advance !

Ivan

#2

Seems like you don’t have an answer yet…
Any chance you are using the software renderer instead of the GPU?

#3

Hello !

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.

#4

Hi,

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.

#5

Even if you are suing the OpenGL API, you can still end up with a software renderer :confused: Nor sure how you can detect these.

#6

Hi Ivan,

Are you sure you’re doing it correctly? It works perfectly here. Summary of what I’m doing:

  1. Create your editor, attach OpenGLContext
  2. Enable vertical sync (setContinuousRepainting(true))
  3. Alter setSwapInterval(x) where the fps will equal monitor refresh rate / x, on the OpenGL thread!

Notice the order matters. setSwapInterval(1) will render at perfect vertical sync, setSwapInterval(0) will render as fast as possible.

2 Likes