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

On 5/3/11 1:30 AM, James Robinson wrote:
>     1)  Resample declarative animations.
>     2)  While (have animation frame callbacks that might need to run)
>        I) If next callback has element, flush style and layout
>       II) Run next callback
>     3)  Process restyles.
>     4)  Do relayout.
>
>     or something.  I would really like to avoid this situation.
>
>
> That's pretty much exactly what the implementation in WebKit currently
> does, except that the algorithm operates on a copy of the callback list
> generated before step 2.

OK.

> In WebKit, style and layout are lazy and
> ensure they are up to date when nothing has changed is very cheap.

That's the case in Gecko as well, but the whole point is that in common 
cases here something will have changed.

> This means if the callbacks are 'well-behaved' and do not manipulate styles
> or layout unnecessarily then the work required by steps 3+4 should be
> minimal

Ah, I see the problem.  You're assuming that the primary use case of 
callbacks is to drive canvas, and hence that manipulating styles is "bad 
behavior".  I'm assuming that it will be just as common to use callbacks 
to replace current style-driven "ticker" animations, so it will be very 
common to have callbacks manipulating style in ways that affect layout. 
  And that these will coexist with callbacks that drive canvas.

> Animation callbacks that cause style recalculations or
> layout to take significant amounts of time are going to be expensive no
> matter what algorithm we use.

There's a difference between "expensive" and "twice as expensive".  I 
don't think that focusing on optimizing the stuff that's already fast is 
a good thing, though it's trendy in today's world of benchmarks using 
geometric means.

> One use case motivating this algorithm is that a page may have multiple
> animations active at the same time that interact with each other, for
> example the contents of a canvas might be animated by one callback while
> the canvas itself or some ancestor is moved by another callback.  In
> that case I want to ensure that the canvas contents are always updated
> when the canvas becomes visible regardless of what order the callbacks
> are registered in.

Yes, I agree that this is a requirement.  Note that my proposed 
algorithm where we fire all the non-element-targeted callbacks and then 
the element ones, with layout flushes for the latter, would solve this 
issue just fine while allowing non-element-targeted style-modifying 
callbacks to not be penalized.

> Since the WebKit implementation copies the list of potential callbacks
> before invoking any of them, all callbacks registered during the invoke
> callbacks algorithm are for the next frame and so it is not possible to
> trigger more than N+1 reflows if there are N callbacks registered at the
> start of the algorithm.

Yes; my claim is that O(N+1) reflows is worse than O(1) reflows.

> In our implementation callbacks that are unfired due to element
> visibility checks are left in the list for next frame.  In the case of a
> single animated canvas outside the viewport Chrome will wake up every
> ~16.7ms

See, that seems pretty undesirable, esp. on mobile platforms.

I don't know how to avoid it yet, though...

-Boris

Received on Tuesday, 3 May 2011 13:42:32 UTC