FR: ComponentAnimator: 60Hz instead of 50Hz

ComponentAnimator does currently use a 50Hz timer:

juce_ComponentAnimator.cpp:

    if (! isTimerRunning())
    {
        lastTime = Time::getMillisecondCounter();
        startTimerHz (50);
    }

60Hz would probably be a more sensible value as AFAIK this is standard pretty much everywhere now: long gone are the days of PAL/SECAM for computer screens :wink:

50Hz animations can look choppy at times on a 60Hz screen.
Changing that value to 60Hz does seem like a simple fix with few possible side effects.

Being able to set that value would be even better, and why not even give the option to use the new VBlankAttachment class?

Might be able to grab some code from AnimatedAppComponent, which seems to do those things already.

Don’t know if that class would be suitable for yours uses for now.

ComponentAnimator has some handy features that I am happy to rely on.
For now I just modify that value in juce_ComponentAnimator.cpp every time I update JUCE…

The refactor I wrote for this (but never put into PR form as I got sidetracked) was simply to allow the caller to specify the refresh rate as a CTOR argument. I think that’s the way to go, possibly including a default value (of 60Hz indeed).

2 Likes

Since the recommended way to use it, for simple stuff, is to use the Desktop::getAnimator(), it would have to default to 60hz.

Speaking of choppy, you might not use a timer at all but resort to VBlankAttachment and make sure to calculate your model against the actual painting time and not a jittery message manager.

Yeah that’s sort of what I was getting at. I had problems with this component when testing the new Direct2D support on Windows, for example.

That is what is done in ComponentAnimator: the progress is calculated in the timer callback.
Components are resized there, and eventually painted later on.
This cannot be as smooth as calculating progress directly in paint(), but cannot be avoided here.