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

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

From: Ali Juma <ajuma@chromium.org>
Date: Thu, 9 May 2013 11:09:26 -0400
Message-ID: <CANLC6v2C_YMembnuG9mKdt3p4GO6nHzAszBD_RJ1cYAG8eo+pA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org, Jon Rimmer <jon.rimmer@gmail.com>
On Thu, May 2, 2013 at 7:52 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:
> The content could start a transition to fade out the spinner, and use
> requestAnimationFrame to start the fade-in of the real content not at the
> next frame, but the frame after. I expect that would give you the behavior
> you want, and it doesn't sound too crazy to me.

If we don’t want the spinner to finish fading out until the expensive real
content can be faded in, we’d have to guess how long the expensive content
will take to paint, and use that guess when determining the duration of the
spinner fade-out. Also, rAF-driven animations would still stall while the
expensive content is being painted.

Taking a step back from this example, the broader goal is to have a way to
add expensive-to-paint content to the DOM, without causing jank or
checkerboarding. So until the expensive content is ready, we want other
painting and drawing to continue as usual, meaning that CSS animations
continue, rAF continues to work, and scrolling is responsive (causing
painting/drawing as usual). Also, rather than checkerboarding the expensive
content until it’s ready, we want the page to behave as if that expensive
content has opacity 0.

Once the expensive content is ready, we want an event fired, so the page
can respond. So, for example, the page might have a placeholder div with
some text (“Loading...”) and a rAF-driven animation (say a spinner), and
once the "expensive-content-is-painted" event is received, the page could
respond by stopping the spinner and fading out the placeholder div.

-Ali
Received on Thursday, 9 May 2013 20:22:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 20:22:52 UTC