- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 22 Aug 2014 07:56:42 +0200
- To: Elliott Sprehn <esprehn@gmail.com>
- 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 Fri, Aug 22, 2014 at 5:37 AM, Elliott Sprehn <esprehn@gmail.com> wrote: > 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. What about mouseover and friends? I guess the best place to define this structure would be in HTML still as that currently defines the event loop as well as microtasks and such. > 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. -- http://annevankesteren.nl/
Received on Friday, 22 August 2014 05:57:09 UTC