When to use requestAnimationFrame?

Question

Having discovered requestAnimationFrame just a moment ago, I have dived into all the information I could find about it. To name just a few of the resources I came across in case there are others looking for more info about it:

• http://creativejs.com/resources/requestanimationframe/ - explains the basics about it.
• http://www.html5rocks.com/en/tutorials/speed/animations/ - explains how to use it.

Anyway, all of these resources tell me something about how requestAnimationFrame works or how it could/should be used, but none of them tell me when it is right to use it.

• Should I use it for animations (repeated changes to the style of an element, much like CSS animations)?
• Should I use it when an automated event wants to change the css/classes of one or multiple elements?
• Should I use it when an automated event wants to change the text value of one or multiple elements? (e.g. updating the value of a clock once every second)
• Should I use it when an automated event wants to modify the DOM?
• Should I use it when an automated event needs values like .offsetTop, .offsetLeft and then wants to change styles such as top and left a few lines further?
• Should I use it when a user generated event causes any of the above changes?

TL;DR: When is it right to use requestAnimationFrame?

Buddie

Since the current accepted answer is quite out-dated and thus doesn't reflect current best practices, please consider to retract the check mark. – Pawpaw

Answer 1

You shouldn't yet. Not really, at least. This is still experimental and may or may not reach full recommendation (it is still a working draft at this point). That said, if you don't care about older browsers, or willing to work with the polyfill available the best time to use it is when you are looking to draw things to the screen that will require the browser to repaint (most animations).

For many simple modifications of the DOM, this method is overkill. This only becomes useful when you are doing animations when you will be drawing or moving items quickly and need to make sure that the browser repainting is keeping up enough to make it smooth. It will allow you to ensure that every frame you calculate will be drawn to the screen. It also provides a utility for more accurate time measurements to your animations. The first argument is the time at which the paint will occur, so you can ensure that you are where you should be at that moment.

You should not use it when you are doing many simple modifications to the DOM, or things that don't need to be smoothly transitioned. This will be more expensive on your users' computers so you want to limit this to making things smoother in transitions, movements and animations. Forcing a frame redraw is not needed every time you make a change on the page, since the response will be fast enough most of the time you don't need to worry about that extra couple milliseconds between draws.

Fedora

This answer is now quite obsolete. requestAnimationFrame now has wide, unprefixed support. It also insinutates that merely calling rAF forces a repaint, which is not correct. – Swale

Answer 2

As the previous answer says, you should not use it in the discontinuous animation because that don't need to be smoothly transitioned. In most cases, it's used for properties which vary continuously with time.

Departed

What is the harm in using it? – Swale

Time may be out of control,the repainted time is determined by the browser. – Departed

You are confusing "repainted time" with "opportunity to possibly do something prior to the next possible repaint". – Swale

I mean, it is unsuitable for skip change in the animation. – Departed

If you have no update to your animation, then you return immediately, and you have wasted a few microseconds. – Swale

Thanks for your help. – Departed