W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: Animation frame task

From: Elliott Sprehn <esprehn@gmail.com>
Date: Thu, 21 Aug 2014 23:37:46 -0400
Message-ID: <CAPJYB1gMp518ioxQVJM3za0g39n=YW5N4Ln0VbXs1dyi5CS5uw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "www-dom@w3.org" <www-dom@w3.org>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "www-style@w3.org" <www-style@w3.org>, Ian Hickson <ian@hixie.ch>, "public-fx@w3.org" <public-fx@w3.org>, Yehuda Katz <wycats@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@google.com>, Adam Barth <w3c@adambarth.com>
On Wed, Jul 30, 2014 at 11:29 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> The concept defined by "Timing control for script-based animations"
>
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html
> 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 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 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
http://jsfiddle.net/vk2x5tL1/show/ 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
colors.

- E
Received on Friday, 22 August 2014 03:38:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC