I’m debugging for my plugin, but found for the iOS version, the pluginEditor is constantly repainting if you just leave the window open, but I didn’t do anything to trigger the repainting at all. Then I checked the desktop version, it works fine, only when the hovering mouse will trigger the pluginEditor to repaint.
Then I created a brand new empty JUCE basic plugin, compile and run it on my iOS device, then I found the same issue, the pluginEditor will constantly repaint without me doing anything.
Just wonder if this is a normal thing that JUCE is designed to be like this, or some kind of bug needs to be fixed, thanks in advance!
Here’s the empty JUCE project you can check it out. And I’m using the latest JUCE development commit 8ed3618e12230ad8563098e1f17575239497b127, iOS16.4.1, macOS Monterey 12.6.5 pureNewBasicPlugin.zip (26.2 KB)
Verified. The main paint() of the editor is called at what I assume is the refresh rate of the device whenever the editor is open. JUCE 7.0.5 master branch, iPadOS 16.5, Xcode 14.3. Repainting persists even if isShowing() is false (for instance, when the host app is backgrounded, isShowing reports false, but the repainting continues)
I’m glad to see I’m not alone in this. We got reports on fast battery drain even in configurations of our plugin where the audio thread does almost nothing (but the UI could do quite a lot if the entire thing needs to redraw).
Unfortunately there are other caveats involved; enabling that flag removes all the benefits of async rendering that we enabled with the release of JUCE 7. We’ll see if we can find something else that restores the previous behaviour.
