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
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?
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).
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.
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.