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

On 5/2/11 7:56 PM, James Robinson wrote:
> 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.

I feel pretty strongly that we need a way to get a time that corresponds 
to animation sampling times.  Date.now() is not it, in my opinion. 
First, it's defined to be wall-clock, not motononic.  Second, it has no 
relation to the timing of declarative animations and I think we really 
do need a way to synchronize declarative and scripted animations.  This 
is why Gecko has mozAnimationStartTime on Window.

It would make some sense to tie this animation clock to the monotonic 
clock we're already using for the timing interfaces; if those allow 
direct access to the current value of the monotonic clock to script, 
then it's sufficient for my purposes to have animations use that same clock.

The rest of the draft looks pretty decent to me at first glance.  A few 
minor quibbles:

1) Canceling a callback is just defined to remove it from L, so that the 
"If the callback has not been cancelled" condition doesn't make sense. 
What's the actual intent here?  Should a callback be cancelable once 
"invoke callbacks algorithm" is entered and the callback has ended up in 
the list copy that algorithm operates on?

2) We need a step between the current steps 3 and 4 of "sample all 
animations" which clears the document's animation frame request callback 
list.

3) Since the "invoke callbacks algorithm" runs on a copy of the list, 
step 2 of that algorithm makes no sense.  It seems to be a refugee from 
when a draft operated on the original list, methinks.  If you're working 
with a copy, you just call the callbacks one by one and are done with it.

> Here's a few of the known issues with this text:
> - "getting the next sample time" algorithm is undefined

Yeah, this could take some work.  Can we reuse whatever SMIL has to say 
here?

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

Yes.

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

For what it's worth, we're planning to add an equivalent parameter in 
Gecko.  Our current approach is to fire the callback if the element's 
"overflow area" (a Gecko-specific concept that basically means the 
bounding box of all boxes generated by the element or any of its 
descendants) intersects the viewport.  For the obvious case of canvas 
this will effectively map to the border-box of the canvas intersecting 
the viewport.  That still leaves open questions like whether the 
border-box used is the one before layout changes caused by some of the 
animations and pending style changes are processed or after...

Thanks for working on this,
Boris

Received on Tuesday, 3 May 2011 00:53:38 UTC