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

On Mon, May 2, 2011 at 5:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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


The 'invoke all callbacks' algorithm is definitely more complicated than it
needs to be with the current text and seems buggy.  The making a copy but
not clearing the original list stuff is indeed leftover from the per-element
visibility text from an earlier draft.  I'll simplify this down to just what
is needed - we can always add text back when we add back the per-element
visibility text.


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


Do you know where I could find that?


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

This is roughly in line with what we're planning to do (although we have not
implemented actual bounds checking yet).  One difficulty is that the
visibility of a given element can change as a side effect of other
callbacks, which complicates the 'invoke all callbacks' algorithm.  For
instance, if a developer registers callback A then B, callback A is
registered on a canvas element initially scrolled out of the viewport and
callback B moves the canvas element into the viewport, then I think the
proper outcome of the 'invoke all callbacks' algorithm would be to first
fire callback B and then fire callback A before terminating.  This means
that the user agent has to iterate through the list of potential callbacks
multiple times, potentially updating style and layout information after
invoking each callback.  It's relatively little code but is a bit subtle.

The more difficult issue with per-element visibility is that in some
browsers (including Chrome and most mobile browsers) the user agent will
lazily render some content that is outside the viewable viewport in order to
be able to scroll more smoothly.  I'm not entirely sure how to specify this
in a way that is both precise for authors and implementors while allowing
some flexibility for innovation.  That said, avoiding work for elements that
are scrolled offscreen can be a big win for users so I think it's worth
figuring out.  For example, on http://www.readwriteweb.com/ today there are
three animated banner ads near the top of page (implemented in Flash), but
lots of content that is only viewable with those ads scrolled offscreen.  If
those were animated using the <canvas> element and requestAnimationFrame it
would be great for users if the ads did not take up any CPU or GPU resources
when they were scrolled offscreen.

Thanks for reviewing the document!

- James


>
> Thanks for working on this,
> Boris
>
>