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

> 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).

Received on Friday, 21 June 2013 17:39:14 UTC