- From: Ali Juma <ajuma@chromium.org>
- Date: Thu, 9 May 2013 11:09:26 -0400
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org, Jon Rimmer <jon.rimmer@gmail.com>
- Message-ID: <CANLC6v2C_YMembnuG9mKdt3p4GO6nHzAszBD_RJ1cYAG8eo+pA@mail.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