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

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

From: Ali Juma <ajuma@chromium.org>
Date: Fri, 21 Jun 2013 12:01:50 -0400
Message-ID: <CANLC6v0Nf=3crxazXKWM60uTSnEgLZko=EjXh=0Xqsmta_VrQA@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On Fri, Jun 21, 2013 at 11:52 AM, François REMY <
francois.remy.dev@outlook.com> wrote:

> [...] rendering events [...]
>>
>
> While I'm not an implementor myself, I don't think any implementor is
> ready to accept the idea of such rendering-fallback events. Triggering a
> rendering-fallback event in order to show a placeholder requires making a
> junction to a JS function running on the main thread before terminating the
> rendering phase. It doesn't seem to me any vendor will be okay to pay that
> price.
>

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.

-Ali
Received on Friday, 21 June 2013 16:02:17 UTC

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