W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css-display]? Compositing, expensive things, and laziness

From: François REMY <francois.remy.dev@outlook.com>
Date: Fri, 21 Jun 2013 18:10:17 +0200
Message-ID: <DUB120-DS131163E5478B9BDA89FCB3A58F0@phx.gbl>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC