- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 21 Jun 2013 18:10:17 +0200
- To: "Ali Juma" <ajuma@chromium.org>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style list" <www-style@w3.org>
> To clarify, what I had in mind wasn't a round-trip > from the compositor (or from rendering) back to > JS. Instead, if the browser is in a state where > optionality will be beneficial (taking into > account the sort of device we're running on, cpu > load, and whatever other factors are useful to > consider), the event would fire immediately in > response to the JS that added the optional > element in the first place. If, for some reason, > this couldn't be fired before the next paint, the > element would stay in the "rendered" state for > that paint. That would probably be possible, but I'm unsure about the gains it would bring. It's not because this frame is lagging that the next one will. Also, if you only intend to influence the next frames, counting the time elapsed between each requestAnimationFrame call can already give incentives to a JS implementation to tweak the layout, right?
Received on Friday, 21 June 2013 16:10:45 UTC