I found an issue on both Demo Runner and my app where, after turning off the screen, the cpu usage jumps from less than 1% to 11%. This happens on both master and develop branches of JUCE. This issue is mostly impacting impared users testing the accessible beta version of my app.
The root cause seems to be in [External Code] which unfortunately is not available.
We’ve had a user report with a similar looking issue to yours on our standalone JUCE app (on Windows). I’ve tested locally with intel integrated graphics on a 13700k, and found our app and the Projucer show similar behaviour with monitors turned off, all on JUCE 7.0.10.
It’s tricky to tell due to the external code calls, but it looks like the VBlankListeners are being called in a fast loop while the monitors are off (presumably because there is nothing to VSync to), but as you’ve found it’s not trivial to debug.
Are you still seeing this issue? Have you had a chance to try JUCE 8 to see if that fixes it?
A fix has been released on develop. This should limit the CPU usage by imposing a 1000 Hz upper limit to the refresh rate. Admittedly this could be improved, but this can significantly reduce CPU usage, and is the same workaround that is currently used by Chrome.
We aim to keep the master branch stable / production ready at all times. There are always some select issues though so answering that question may depend on your individual circumstances.
This work is relevant to this FR: FR: Animation frame rate limits, so I guess improvements could be to have a configurable JUCE default max FPS (like 120Hz), “smartly” makes sure resulting frames are evenly spaced based on the runtime hardware refresh rate, etc…
It could be possible to track the on/off state of the display by using verbose APIs to track multiple OS events and throttle the redraws way down in these situations.
