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

It's important that we have normative text describing the number of callbacks should match the refresh rate of the display. This ensures that animations don't over or under draw relative to the display painting.

For hidden pages, we need to ensure that we eliminate or greatly reduce the rate of callbacks to efficiently use system resources. The benefit of eliminating callbacks is that animations will be paused when the user can no longer view them, most efficient use of system resources and it will be a very simple algorithm to implement. If we do decide to go down the route of greatly reducing the callback rate, we may want to leave the exact algorithm up to the user agent. 

I don't particularly feel strongly about the inline script or additional arguments. The goal here is to ensure that developers can easily convert their existing code to use this API. I don't think the API is overly complicated as is.

I do feel that we need to make the element argument optional. The simple use case of requestAnimationFrame() will not use the element argument.

Thanks,
Jatinder

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Boris Zbarsky
Sent: Monday, May 02, 2011 6:29 PM
To: public-web-perf@w3.org
Subject: 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 02:18:03 UTC