Well, it works but timing the animation through any fixed delay (frame rate) appears to make the duration quite inaccurate.
Maybe it’s a bit hard to compare with different speeds.
This was odd because both were calculated at 60 fps. So they should take just as long. Turns out using a setTimeout only at 17ms a frame for an animation of 500ms comes down to about 730ms. That is ‘forcing’ each frame – letting requestAnimationFrame optimise the timing brought it close to a full second! That’s why the animation didn’t look as smooth as letting the API run the best timing by itself.
Anyway, thought it better to get rid of the frame rate (that’s pretty much the of point this feature) and rewrote it to some ad hoc progress timing with
new Date().getTime(). Very smooth and nicely timed now.
I’ll definitely be using this a lot!