TL;DR: requestAnimationFrame speeds vary by browser and display refresh, so avoid being lazy like me, and don't use frame counts to time animations.

Working on a new algorithmic art piece I was surprised to find that Chrome was rendering the animation at 2x speed when compared to Safari. Weird. It turns out the culprit was a combination of browser variation in the JS function requestAnimationFrame and my lazy coding of trying to use frame counts to time animation instead of calculating elapsed time (I know, not a great idea).

A little digging turned up that requestAnimationFrame in Chrome runs at 120Hz when viewed on a Mac with a ProMotion display, where Safari caps the speed at 60Hz. Turning to MDN it turns out that my understanding of the function was completely wrong despite having used it for years. I assumed that it was always 60Hz unless the system was having difficulty keeping up, but no, it's actually tied to the refresh rate of the display. I guess Apple was worried about the higher Hz impacting battery life¹ so prevented the higher speeds. Safari for some reason still lets CSS animations run at 120Hz, so now timing between CSS and JS is out of sync. Sigh.

I guess it's time for me to think about creating a simple animation engine instead of using hack workarounds.