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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 3 May 2013 10:16:06 -0700
Message-ID: <CAAWBYDCzb-5n8bk0LGzq2KmU=sECCKZRb_7gSB6nPqSRd0u8Kg@mail.gmail.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: www-style list <www-style@w3.org>
On Thu, May 2, 2013 at 10:33 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> On 5/2/13, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Whenever something changes in the document tree, Blink waits for
> What is 'Blink'?

Chrome's rendering engine.  (We recently forked from WebKit.)

>> The container holds some expensive-to-paint content - a video with a
>> mask and a box shadow and an animated border radius, I dunno.  When
>> the video sufficiently preloads, JS adds a "ready" class to the
>> container, which fades the spinner out and fades the content in.
> I was trying for quite a while to understand why you would want a
> spinner. Finally, It occurred to me that what you meant is not a
> spinner, but a busy/wait indicator. A spinner is a UI input widget --
> totally different.
> So the program can define videoReady and the callback for videoReady
> can add a class to the container, triggering the cascade. That sounds
> like about what you want.

"Spinner" is a common name for a wait indicator as well (since many
wait indicators are just something spinning/orbiting in a circle).

>> As an obvious optimization, we skip painting content that is fully
>> transparent, so the expensive content hasn't been painted yet before
> Skip painting? What exactly is your code doing to skip painting?

This is not "my" code; that is, I'm not talking about author code.
I'm discussing compositor code here, stuff in Blink rather than in the

Browsers do various optimizations to avoid painting things until they
absolutely have to.

>> the transition triggers.  Due to our compositor design, this means
>> that we delay *both* transitions (for the spinner *and* the expensive
>> content) until the expensive content is painted and ready to start
>> fading in.
>> Sometimes, this is the behavior you want.  Often, it's not, because
>> you want the page to start responding immediately, not after 100ms
> 100ms delay? Where are you getting that figure?

A pulled-out-of-my-ass number for the amount of time it takes to get a
first paint done for the expensive element.  Exact number isn't
important; point is that it's an observable length of time, and when
*all* of the transitions are delayed by that amount, produces a
user-noticeable "hitch" in the page.  We already know that this is a
thing that happens in real content, which is why I'm starting this
conversation.  ^_^

Received on Friday, 3 May 2013 17:16:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC