Using PC Hardware more efficiently in HTML5: New Web Performance APIs, Part 1


Browsers need amazing performance to deliver on the promise of HTML5 applications. Web developers need API’s to efficiently take advantage of modern PC hardware through HTML5 and build high performance Web applications with efficient power use for great, all around customer experiences. The second IE10 Platform Preview supports three emerging API’s from the W3C Web Performance Working Group which enable developers to make the most of the underlying hardware and use battery power more efficiently: requestAnimationFrame, Page Visibility and setImmediate.

Together with Google, Mozilla, and others on the W3C Web Performance Working Group and the community, we designed these new API’s over the last three months. These three API’s are a great example of how quickly new ideas can become interoperable standards developers can depend on in modern HTML5 enabled browsers.

This post details how to use the requestAnimationFrame API for better performance and power efficiency.

requestAnimationFrame API: like setTimeout, but with less wasted effort

Web developers can now schedule animations to reduce power consumption and choppiness. For example, animations today generally occur even when a Web site is in a background tab, minimized, or otherwise not visible, wasting precious battery life. Animations today are not generally aligned with the display’s refresh rate, causing choppiness in the animation. Until the requestAnimationFrame API, the Web platform did not provide an efficient means for Web developers to schedule graphics timers for animations.

Let’s take a look at an example. Most animations use a JavaScript timer resolution of less than 16.7ms to draw animations, even though most monitors can only display at 16.7ms periods (at 60Hz frequency). The first graph below represents the 16.7ms display monitor frequency. The second graph represents a typical setTimout or setInterval of 10ms. In this case, the consumer will never see every third draw because another draw will occur before the display refreshes. This overdrawing results in choppy animations as every third frame is being lost. Reducing the timer resolution can also negatively impact battery life by up to 25%.

Diagram showing how every third redraw cycle is wasted with setTimeout-based animation
At top, each arrow represents a monitor refresh at 16.7ms periods. Below is a 10ms page redraw cycle. Every third redraw is wasted because the monitor will never show it. The result is choppy animations and wasted battery.

The requestAnimationFrame API is similar to the setTimeout and setInterval API’s developers use today. The key difference is that it notifies the application when the browser needs to update the screen, and only when the browser needs to update the screen. It keeps Web applications perfectly aligned with the browser’s painting, and uses only the necessary amount of resources.

If you take a look at this requestAnimationFrame example, you will notice that even though the animations look identical, the clock drawn with requestAnimationFrame is always more efficient in power consumption, background interference and CPU efficiency than the setTimeout clock.

Screen shot of the requestAnimationFrame API Test Drive demo
The requestAnimationFrame animation (right) is more efficient in power consumption, background interference and CPU efficiency than the setTimeout animation (left).

It is a simple change to upgrade your current animations to use this new API. If you are using setTimeout(draw, PERIOD); in your code, you can replace it with requestAnimationFrame. The requestAnimationFrame API is the furthest along of these three API’s with vendor prefixed interoperable implementations available starting with Firefox 4, Chrome 13, and IE10.

Remember, requestAnimationFrame only schedules a single callback, like setTimout, and if subsequent animation frames are needed, then requestAnimationFrame will need to be called again from within the callback. In this Platform Preview, IE implements the API with a vendor prefix like other browsers. Here is an example of how to write cross-browser mark-up that is future proof:

// Future-proof: when feature is fully standardized

if (window.requestAnimationFrame) window.requestAnimationFrame(draw);

// IE implementation

else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw);

// Firefox implementation

else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw);

// Chrome implementation

else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw);

// Other browsers that do not yet support feature

else setTimeout(draw, PERIOD);

Thank you, to everyone in the W3C Web Performance Working Group for helping design these APIs, and thanks to other browsers, for starting to implement these APIs with an eye towards interoperability. With these APIs, Web developers can create a faster and more power conscious Web.

—Jatinder Mann, Internet Explorer Program Manager

Comments (16)

  1. Jack says:

    Great to see IE is also supporting this API!

  2. Mathias Bynens says:

    What about Opera?

  3. Cameron McCormack says:

    Nice work, Jatinder!

  4. Tom says:

    Opera supports or will support window.oRequestAnimationFrame if I know well.

    I can't test it, sorry.

  5. Boink says:

    So what now about displays with a refresh rate other than 60 Hz? Firefox has 60 fps as its default no matter what monitor you have but offers an about:config setting for changing that, will IE10 be similar? How will future versions behave (so that web designers don't get the idea that it's always and for all times 60 fps).

  6. 8675309 says:

    its nice to this in all but most sites still use flash

  7. jader3rd says:

    @8675309

    Saying that there's no need to create new stuff, because current implementations use old stuff is a luddite attitude and is not very helpful, and restricts the potential of where new technologies may take us.

  8. morgan says:

    So just because Microsoft has lost in the mobile space doesn't mean they have the right to take out their sour grapes complaints and steal money from other vendors:

    http://www.osnews.com/…/Microsoft_Demands_15_for_Every_Samsung_Android_Phone_Sold

    Microsoft did not write Linux or Android, nor did they make HTC or Samsung hardware!

    When Microsoft pulls crap like this, Microsoft loses face in ALL DEPARTMENTS!

    Note that again! By pulling this crap in lawsuits against Mobile hardware manufacturers you are making develops NOT WANT TO DEVELOP ON OR USE MICROSOFT TECHNOLOGY – including your flagship software – Internet Explorer!

    Not impressed Microsoft.  Not impressed at all.

  9. samiam says:

    @morgan

    You have it reversed. MS has patents that were stolen by Android. They are just getting back what was stolen from theme.

  10. MikeGale says:

    On the performance call.  It's great to see the browser makers pulling together on this one.  It illustrates what can be done before standards are ratified.  I probably see badly thought out Javascript sucking up cycles every day, this will help when it gets good market penetration.

    On the off topic patent rant.  Don't shoot the messenger.  The existence of software patents is the issue.  If they're there you use them.  The other guy certainly will, so you have little choice.  (A day or two ago 4.5 billion was paid for 6000 Nortel patents (insolvency case).  The winning consortium included Apple, Microsoft, RIM and Sony-Ericsson.  Google lost.  Are you going to hate all these guys because they play the hand the're dealt?  Now Apple, MS, RIM, Sony etc. will need to justify the huge cost they've just undertaken, consumers will feel it I imagine.  These guys didn't create the patent system!)

    I don't know how this patent mess gets changed.  If you know a way, have the time, inclination and ability, get stuck in!

    (The US Legislature is in the process of passing measures which change the game, maybe for the worse in the long run.  Not sure if there's much attention paid to what that means.  It might entrench patents instead of fix the system.)

  11. Olivier says:

    @morgan : nobody care if you don't want to develop for Microsoft platforms. You're just losing market share :P

  12. Julian Reschke says:

    Adam Barth observes that your code example with respect to feature detection is broken. See lists.webkit.org/…/017537.html and subsequent thread.

  13. Developer says:

    Shouldn't efficiency be measured in expected_callbacks / actual_callbacks?

    Nothing that can be more than 100% efficient.

  14. pepees says:

    a test with Linux and mac?

  15. RF says:

    Might IE lower the ratelimit from 60FPS to save battery or prevent stutter?

    I imagine that 30 FPS would look fine if it improves battery life, and might even look better than 60 FPS with erratically dropped frames.

  16. RF says:

    Also: I disagree with Adam Barth. Any code targeting draft standards might break. That doesn't lock the W3C in to never changing the draft. It's "beta": nobody makes us authors use it, and if we do, the burden's on us to adapt if it breaks, changes, etc.