Hey devs!
Happy to read that JUCE7 is on the horizon.
I’d like to bring to your attention that with the current windows rendering, there is a need for repaint throttling too.
The reason is, that external influences can lead to a lot of unnecessary repaints per frame, with brutal effects on rendering performance even if the plugin gui doesn’t do any much involved rendering. I’m talking about freezing DAW guis, it quickly gets worse if multiple plugin windows are open.
In particular, these two scenarios are easy to reproduce:
- moving sliders with the mouse
- ui elements being updated due to automation attachments
In both cases, the issue is that the windows message system can easily send many more WM_PAINT calls than would be necessary for a single frame. Those follow directly on InvalidateRect. If you have one of those high dpi mice, they tend to send more moves per frame than your typical screen refresh rate, and automation is tied to buffer size. I was able to observe InvalidateRect > WM_PAINT successions exceeding 200 fps, each time causing actual paints of the involved components.
The fix I implemented will queue invalidated rectangles up to a specifieable max delay (10-15ms works well), before handing them over to windows via InvalidateRect. So this is one way to do it with the existing rendering. There is no way to sync to screen fps which I know of, that GDI winapi stuff is super archaic, but as long as you always send the first invalidate immediately and only apply queuing/delayed invalidate afterwards, it still feels responsive enough.
I’d welcome it to see a mechanism like this in JUCE7 (as long as there is no new renderer for windows), because currently it is the only reason for me to carry around and maintain a modified version of JUCE.
Thanks!