Re: Animation frame task

On Wed, Jul 30, 2014 at 11:29 AM, Anne van Kesteren <>

> The concept defined by "Timing control for script-based animations"
> seems to be more widely applicable and needs to be made extensible.
> In particular user agents are interested in processing scroll events,
> media query evaluation, fullscreen state changes, orientation changes,
> and probably much more layout related matters in the same task.
> See for some context.
> This argues that this animation frame task needs some internal
> queuing. Either we need buckets so scroll events are always processed
> before any fullscreen state changes, or we need a simple FIFO queuing
> mechanism on a per-task basis.
> Who will take ownership of this?
Blink does FIFO on "animation frame events" and then processes
requestAnimationFrame callbacks after that. Currently we process scroll
events, media queries, resize events, and the overflowchanged event in the
FIFO queue. We plan to move more things there in the future (probably
everything you listed). I don't think we want an explicit ordering in the
queue, it should work just like the microtask queue with promises. Blink
also has a concept of a unique event, specifically it'll only ever fire one
scroll event per frame, even if there's many scrolls in that time period.

I also think there's value in spec'ing how RAF interacts with rendering,
since it seems browsers disagree a lot there. An example is Here setInterval and RAF are setting two
different colors. In Blink RAF always wins, because we layout and paint
immediately after RAF. In Firefox which one wins seems to be totally
arbitrary, you can refresh repeatedly and get stuck with a different color
each time. In Safari and IE it will flicker constantly between the two

- E

Received on Friday, 22 August 2014 03:38:54 UTC