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

On 5/2/13, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Prepare for some exposition.
>
> Whenever something changes in the document tree, Blink waits for
What is 'Blink'?

> everything affected by the change to finish responding to the change
> before pushing the pixels to the screen, or doing other things such as
> running animations.
>
> For example, say you have CSS like the following:

A familiar approach!

Toggle Class To Trigger Descendant Selector Rules
http://jibbering.com/faq/notes/code-guidelines/descendant-sel.html

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

> 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?

> 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?

I'm lost on the rest.
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

Received on Friday, 3 May 2013 05:34:10 UTC