RE: [AnimationRequestFrame] Initial editor's draft of AnimationRequestFrame spec available

James, thanks for getting the spec on to http://dvcs.w3.org/hg/webperf. I have some feedback on the current draft:


1.       As you mentioned, the draft does not address the rate of callbacks for the requestAnimationFrame API when used in a tight loop. One of the benefits of this API is that it will align drawing of animations with the refresh rate of the display. This includes being aware of page visibility.



The specification should provide normative text that describes the rate of callbacks when the page is visible and not visible. I recommend adding the following text:

"When the requestAnimationFrame method is called in a tight loop, the number of callbacks should match the refresh rate of the display. For example, on a 60Hz display a callback should be returned every 16.7ms. If the page is not visible, as defined by Navigator.visible attribute being false in the Page Visibility specification, the requestAnimationFrame method will not return a callback."


2.       To increase adoption of the requestFrameAnimation(), it should be syntactically similar to window.setInterval() or window.setTimeout(). This means that in addition to taking a FrameRequestCallback, we should also allow inline script and additional arguments. For example,


long requestAnimationFrame(in FrameRequestCallback callback, in optional Element element, in any... args);

            The specification can give the following examples:


handle = window . requestAnimationFrame( handler [, arguments ] )
Schedules a timeout to run handler prior to the display refresh. Any arguments are passed straight through to the handler.


handle = window . requestAnimationFrame( code )
Schedules a timeout to compile and run code prior to the display refresh.


3.       The specification should be clear that the element argument in the requestAnimationFrame method should be optional and not a normative requirement. I recommend adding the 'optional' text like so:



long requestAnimationFrame(in FrameRequestCallback callback, in optional Element element, in any... args);



4.       More information is needed on the sample() method of the FrameRequestCallback interface. A non-normative example use case would be appropriate.



5.       The Introduction section should have an example use case of this API. This can be the canonical example of replacing existing use of setTimeout() or setInterval() with this API.

Thanks,
Jatinder


From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of James Robinson
Sent: Monday, May 02, 2011 4:56 PM
To: public-web-perf@w3.org
Subject: [AnimationRequestFrame] Initial editor's draft of AnimationRequestFrame spec available

I've uploaded a first editor's draft of the AnimationRequestFrame spec to http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/AnimationRequestFrame/Overview.html (current version is http://dvcs.w3.org/hg/webperf/raw-file/02822501c985/specs/AnimationRequestFrame/Overview.html).  We have a bit of work to do but this document should provide a useful starting point.

Here's a few of the known issues with this text:
- "getting the next sample time" algorithm is undefined
- The specifics of what it means for a user agent to "continually sample all animations" is undefined.  We'll need to add some text here indicating the user agent should update animations taking into account the page's visibility with some accommodation for browser-level throttling and flow control.

Additionally, we've experimented in Chrome with adding an element parameter to requestAnimationFrame in order to do more specific visibility testing.  I think this functionality is useful but it will require some refining to come up with a consistent and well-defined description of what this means.  For now, I've left this parameter out of the spec.

- James