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. -AliReceived on Friday, 21 June 2013 16:02:17 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC