Tuesday, September 21st, 2010

Animating With Firefox’s mozRequestAnimationFrame

Category: Animation, Firefox

Firefox 4 is going to be a very exciting release. Robert O’Callahan details one of the new features, which should help animation, called mozRequestAnimationFrame. First the motivation:

In Firefox 4 we’ve added support for two major standards for declarative animation — SVG Animation (aka SMIL) and CSS Transitions. However, I also feel strongly that the Web needs better support for JS-based animations. No matter how rich we make declarative animations, sometimes you’ll still need to write JS code to compute (“sample”) the state of each animation frame. Furthermore there’s a lot of JS animation code already on the Web, and it would be nice to improve its performance and smoothness without requiring authors to rewrite it into a declarative form.

setTimeout and setInterval can only go so far; as Robert describes, we sometimes need something between purely JavaScript-driven animation using setTimeout and having to go full declarative using CSS3 or SMIL. mozRequestAnimationFrame is one potential way to get better synchronization and performance from JavaScript based animation.

Some sample code from Robert using it:


  1. var start = window.mozAnimationStartTime;
  2. function step(event) {
  3.    var progress = event.timeStamp - start;
  4.    d.style.left = Math.min(progress/10, 200) + "px";
  5.    if (progress < 2000) {
  6.       window.mozRequestAnimationFrame();
  7.    } else {
  8.       window.removeEventListener("MozBeforePaint", step, false);
  9.    }
  10. }
  11. window.addEventListener("MozBeforePaint", step, false);
  12. window.mozRequestAnimationFrame();

It’s not very different from the usual setTimeout/Date.now() implementation. We use window.mozAnimationStartTime and event.timeStamp instead of calling Date.now(). We call window.mozRequestAnimationFrame() instead of setTimeout().

Note that you will generally get about 50 frames per second using mozRequestAnimationFrame. As Robert describes in another blog post, this is a feature not a bug:

On modern systems an application usually cannot get more than 50-60 frames per second onto the screen…So even if an application updates its window 100 times a second, the user won’t be able to see more than about half of those updates…firing a MozBeforePaint event more than about 50 times a second is going to achieve nothing other than wasting CPU (i.e., power). So we don’t. Apart from saving power, reducing animation CPU usage helps overall performance because we can use the free time to perform garbage collection or other house-cleaning tasks, reducing the incidence or length of frame skips.

I hope that other browsers pick up this feature.

Posted by Brad Neuberg at 7:00 am
1 Comment

2.8 rating from 19 votes

1 Comment »

Comments feed TrackBack URI

Also, you can use:


Comment by paulrouget — September 21, 2010

Leave a comment

You must be logged in to post a comment.