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

On Fri, Jun 21, 2013 at 10:38 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> Note that Ali is an implementor for Blink, and the proposal doesn't
>> interrupt the renderer at any point - the event just informs script
>> when the element has been rendered.
>
> Yes, I misunderstood the fact the event was asynchronous, not synchronous.
> But still, I'm wondering whether an event is the right way to deal with
> this.
>
> This is just a random thought, but would
> "HTMLElement:requestAnimationFrame(callback)" do the trick? The callback
> would be called roughly at the same time as window.requestAnimationFrame,
> but only whenever the element is ready for his next paint. That way, you can
> know how much time it takes to render that element (ie: the specific frame
> rate of the 'lazy' element). In the case of non-lazy elements, calls would
> be synced with the nearest lazy element, or the window. The advantage of
> this solution is that it's easy to polyfill:
>
>    // this browser does not support lazy elements
>    HTMLElement.prototype.requestAnimationFrame =
> window.requestAnimationFrame.bind(window);
>    HTMLElement.prototype.cancelAnimationFrame =
> window.cancelAnimationFrame.bind(window);
>
> A positive point of this this solution would be that it enables further
> optimizations like not firing the element's rAF when the element is
> offscreen. A negative point is that it's less useful to provide an
> alternative content (but the alternative content of a lazy element could be
> defined as the last frame ever being rendered, or an empty bitmap if it
> never was).

Read earlier in the thread - rAF doesn't quite have the right
semantics for this.

~TJ

Received on Friday, 21 June 2013 17:59:24 UTC