Shall the requestAnimationFrame calls always be throttled down to 60 FPS?

Question

requestAnimationFrame is called whenever the screen is ready for a repaint. On modern screens the refresh rate may be a lot higher then 60 frames per second. If there is a lot of stuff going on inside those calls - it may impact the overall performance of the application.

So my question is: shall the requestAnimationFrame always be throttled down to 60FPS? Can human eye actually tell the difference between for example a 16ms and an 8ms repaint delay?

[UPDATE] I ended up throttling it down to 60FPS for higher performance on screens with high refresh rate. And would suggest this approach to everyone who has a lot of stuff goin on inside the rAF calls. You should do your own testing of course though.

Answer 1

Per MDN it will not necessarily always be 60 FPS.

Relevant quote:

This will request that your animation function be called before the browser performs the next repaint. The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation. The callback rate may be reduced to a lower rate when running in background tabs.

As for can the human eye distinguish 60 vs 120 FPS, well, that's an open, and opinionated question. Some claim to see it, other's claim its impossible. Allowing the end user to choose is (or simply using their hardware to its fullest) probably best.

As markE's comment pointed out. The requestAnimationFrame callback receives a DOMHighResTimeStamp which is a high precision timer accurate to the "thousandth of a millisecond." By using this time-stamp, and calculating the delta between frames, you can tune your refresh rate to whatever desired value.

References:

• requestAnimationFrame
• W3C Timing control for script-based animations
• DOMHighResTimeStamp

Note: please remember to leave a comment addressing any downvotes, otherwise they are not useful feedback.