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

On 5/2/11 9:16 PM, Jatinder Mann wrote:
> “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.“

For what it's worth, that may not match what declarative animations 
(e.g. SMIL) do.  In particular, declarative animations make promises 
about events firing "eventually" with no allowances for hidden pages.

What Gecko does is to throttle declarative animations and 
requestAnimationFrame callbacks to 1Hz in Fx4.  In Fx5 we switched to an 
exponential backoff approach instead.  I think something like that may 
be better than simply not calling the callbacks.  In particular, it 
allows the animations to actually finish in the background; it's not 
clear to me whether just not calling the callbacks would do that.

> 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.

I actually disagree on this.  Additional arguments add a lot of 
bookkeeping for a very rarely used edge case; authors who need that edge 
case can use a closure explicitly.  Also, note that allowing 
pass-through arguments here would preclude later adding an optional 
element argument unless we bake that optional element argument into the 
very first spec version.

Similarly, I don't think we should allow string arguments: they're a 
security antipattern and we shouldn't add more such.

-Boris

Received on Tuesday, 3 May 2011 01:29:38 UTC