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

On 5/2/11 10:17 PM, Jatinder Mann wrote:
> It's important that we have normative text describing the number of callbacks should match the refresh rate of the display.

As a should-level requirement, sure.

> For hidden pages, we need to ensure that we eliminate or greatly reduce the rate of callbacks to efficiently use system resources.

Agreed.

> The benefit of eliminating callbacks is that animations will be paused when the user can no longer view them

Yes, but is that what the user would want?  That is, pause the 
animation, but then immediately complete it when showing that page again?

> most efficient use of system resources and it will be a very simple algorithm to implement.

At least in Gecko's case it's not, fwiw.  It's much simpler to throttle 
the rate.

> 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'd be fine with that.  Note that just throttling means that the _same_ 
algorithm can be used for SMIL and for requestAnimationFrame callbacks, 
which I think is desirable.

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

I think we all agree on that.  It's optional in WebKit, and would be 
optional in Gecko.

-Boris

Received on Tuesday, 3 May 2011 02:24:11 UTC