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

On Mon, May 2, 2011 at 6:48 PM, Boris Zbarsky <> wrote:
> On 5/2/11 9:24 PM, James Robinson wrote:
>> 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.

On the other hand, if you do want to implement the feature James is
talking about here, you'd end up with:

1)  Resample declarative animations.
2)  Run animation frame callbacks if any.
3)  Process pending restyles, if any.
4)  Do relayout, if needed.
5)  If something with an animationcallback has been moved into the
screen, goto 2.

In the common case, when no objects *just* crossed the edge of the
screen, this still results in just one reflow. Only right when an
object moved in will it require two.

However you would probably want to use some fuzzy logic so that
objects that are right on the edge, or just moved off the screen,
still get their callback called, so that you don't end up with
something that walks the edge of the screen cause cause double reflows
for a large number of runs through the algorithm.

/ Jonas

Received on Tuesday, 3 May 2011 02:07:10 UTC