[Webkit-unassigned] [Bug 51218] New: Implement mozilla's requestAnimationFrame API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51218

           Summary: Implement mozilla's requestAnimationFrame API
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jamesr at chromium.org
                CC: fishd at chromium.org, simon.fraser at apple.com,
                    kbr at google.com, vangelis at chromium.org, gman at google.com


Mozilla has proposed an API to coordinate and rate limit imperative animations: http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html.  The basic idea is that instead of imperative animations driving themselves off of setTimeout()s, the author would inform the browser of elements that are animated and the browser would tell the page when to update the animation state.  I think we should implement something similar in WebKit.

Here are the goals that I think are important (I'll talk about possible implementations in comments):

1.) Make it easy for authors to write animation code that does not waste CPU updating animations that are not visible.  A WebGL game or Canvas 2D banner ad should not be consuming lots of resources when they are in a background tab or scrolled well outside the viewport.  Web developers are for the most part lazy so we should make the easy way efficient and not require a lot of work on the developer's part.

2.) Allow the browser to rate-limit animations to a reasonable target framerate and adapt to slow running JS.  On most displays it makes no sense to update animations at faster than 60Hz, but authors who write setTimeout(.., 0) may try to run faster today.  Additionally we should have some flexibility when dealing with pages that have some content that updates very slowly (say some highly complex WebGL-rendered scene) in order to not lock the entire page to the framerate of the slowest element.

The W3C FX task force has expressed interest in this proposal.  We should provide any feedback to them and be responsive to any input they might have.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.