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

On Mon, May 2, 2011 at 11:05 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, May 3, 2011 at 1:48 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> Robert, do you have any opinions here?  If you're not on this list, maybe
>> you should be!
>>
>
> Another spec list? OK, my inbox runneth over!
>
> I agree with James that we should guarantee that every element that's
> visible when we paint should have had its animation callback(s) called. That
> means some kind of potentially bad iteration is needed. On the other hand we
> should NOT make any guarantees about callbacks not being called. So we would
> be allowed to always call all of them if we want.
>
> Then we can improve the iterative algorithm a bit by running callbacks as
> soon as we think they are likely to be needed, like so:
> 1) Resample declarative animations
> 2) Run all animation callbacks with no associated element (we know these
> need to run, best to run them first)
> 3) While there are callbacks that have not run yet:
>   a) Flush restyles and layout
>   b) Compute the set of callbacks that have not run yet whose elements are
> currently visible in the viewport
>   c) If that set is empty, go to step 4
>   d) Otherwise, run all those callbacks
> 4) Flush restyles and layout
> 5) Paint
>
> Then we'd only need multiple iterations of step 3 if an animation callback
> actually makes another animated element visible. I would hope this is rare.
> The tradeoff is that we might run an animation callback unnecessarily when
> another animation callback has made the element invisible, but that should
> also be rare.
>

This can help in some cases, but does not improve the worst case (for
example http://webstuff.nfshost.com/raf-make-visible.html where each
callback changes the visibility of another element by toggling the
style.display property between "blank" and "").  Any algorithm that promises
not to miss any visible elements will have to recalculate visibility once
per callback or end up invoking the callback for elements that are
definitely not visible.  I also think it's not obvious that invoking the
callbacks will typically be cheaper than reevaluating the visibility
criteria.  Animation callbacks can be expensive (for example the callbacks
at http://webglsamples.googlecode.com/hg/aquarium/aquarium.html take a
decent amount of CPU and GPU resources on my box) and updating styles+layout
can be very cheap in some cases.  I'm a little wary of calling into
arbitrary javascript with unknown performance to try to shave off a bit of
calculations in C++ that is somewhat more predictable.  The ideal behavior
will depend on the particulars of the page, of course, but I am not yet sure
which approach will be better in most cases.

Since we don't yet know how people will use this in the wild, I think the
best course of action is to try to collect some implementation experience
and see what ends up working well in practice.  jQuery's animation system
uses rAF to drive its central animation tick (
https://github.com/jquery/jquery/blob/master/src/effects.js#L407) which
powers many callbacks associated with many elements so it's not clear that
they will be able to use the element parameter as it exists right now
anyway.

I think we can accommodate both your proposed algorithm and the current
WebKit implementation by defining the visibility requirement sufficiently
loosely so that the user agent can use potentially stale style+information
to decide that an element might be visible, so long as it ensures that no
callbacks are left pending with definitely visible elements at the end of
the algorithm.  Authors will have to expect that their callback may be
invoked when the element is not visible anyway, and the default behavior of
updating the animation anyway should be fine.

The drawback of leaving this loose is that the order of callback invocation
will change depending on the details of the algorithm.  For example, in
http://webstuff.nfshost.com/raf-visible-ordering.html the callbacks run in
the order A, B, C in WebKit currently, but would run in the order A, C, B in
Robert's proposed algorithm.  This has a chance of tripping up some authors.

- James


>
> Unfired callbacks need to stay in the list so that if the element becomes
> visible, a callback fires. However, we can avoid wakeups by observing that
> we only need to reschedule a scan of the list if a reflow or scroll
> operation has occurred. Then for a page that's quiescent apart from an
> animation callback for an element outside the viewport, we wouldn't wake up.
>
> Rob
> --
> "Now the Bereans were of more noble character than the Thessalonians, for
> they received the message with great eagerness and examined the Scriptures
> every day to see if what Paul said was true." [Acts 17:11]
>