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

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

OK.  My personal preference is to make a copy, clear the list, and then 
fire the callbacks.  That means you can't cancel a callback at that 
point, but I think that's fine....

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

http://www.w3.org/TR/smil-animation/#TimingModelDetails if it's defined 
in there at all, I suspect.

> 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

Indeed.  That's the really hard problem, since detecting this can be 
very expensive (requires style and layout updates).

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

This is something I'd dearly like to avoid, actually, so I'm not sure 
it's as simple as we'd like it to be.

The current ordering in Gecko when a sample happens is like this:

1)  Resample declarative animations.
2)  Run animation frame callbacks if any.
3)  Process pending restyles, if any.
4)  Do relayout, if needed.

This ensures the following properties:

* If animation frame callbacks query style information, it has already 
been updated for running declarative animations (SMIL, CSS Transitions, 
CSS Animations).
* If animation frame callbacks play nice (don't read style/layout data, 
just update their own state and set style accordingly), there is only 
one restyle pass and one relayout pass.

This allows animation frame callbacks that do non-canvas animation to do 
so in the most performant way possible.

Now the interesting thing here is that animation frame callbacks that 
would most benefit from an element argument (canvas) won't trigger any 
style or layout changes in the typical case.  So maybe we could specify 
that all the callbacks that don't include an element run, then layout is 
updated and then the callbacks that include an element run, with layout 
updates before each one just in case they do mess with style and layout 
and perhaps another layout update after the last one so that layout is 
actually up to date at the end of all this.  That should make the common 
cases fast at the expense of animation frame callbacks that are scoped 
to an element but mutate its style....  Hopefully that's ok.

Robert, do you have any opinions here?  If you're not on this list, 
maybe you should be!

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

Hmm.  We could allow the callbacks to fire outside the viewable 
viewport, but not require it.

Another open question is what happens to unfired callbacks.  Do they 
just get left in the list, or what?  Consider a single canvas outside 
the viewport; in an ideal world we'd be able to do nothing with it until 
it goes into the viewport (as opposed to waking up every 16.7ms to check 
whether it might be inside the viewport now).  That seems like it 
imposes a burden on the author, though...

-Boris

Received on Tuesday, 3 May 2011 01:48:36 UTC