shouldThrottleRepaint() today

Hi folks,

Just looking for some insight, as I’m new to JUCE.

shouldThrottleRepaint() located at line 959 of juce_mac_NSViewComponentPeer.mm seems to make horizontally moving components appear laggy. Bypassing this throttling mechanism improves the visual appearance.

After lurking the forums, I see it was added for a reason. I’m just wondering if it’s still relevant? Would removing it be opening a can of worms? Has anyone else stumbled upon this and come to any conclusions?

As far as I know, this is still an issue, and probably even more so now that 60 fps is the generally the minimum framerate for a modern display and many support 120fps+.

I believe the JUCE team is working on fixing the root cause of it rather than adding an option to turn off the throttling or making minimumRepaintInterval configurable (as @t0m alluded to here: Is the JUCE team still here? - #2 by t0m)

One way around it at the moment is to use the OpenGL renderer, but that comes with its own set of issues/complications.

1 Like

Just to update on this issue: this is an even bigger problem now that the OpenGL renderer is essentially unusable for 2D drawing on Apple M1 machines.

@goodhertz I’m just following you along this journey lol –

Bumping this thread as well – it seems like modern day CoreGraphics rendering is totally capable of handling animations, however the way this repaint throttling is happening is strange with the constant attach & release of components from the timer thread – I see that there’s no perfect way to handle this, but for animated components without using the GL renderer, I think we need more control in our code in how this is handled

1 Like