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