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:39:02 UTC