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