On Thu, May 9, 2013 at 11:34 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
> On Thu, May 9, 2013 at 8:23 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> Right, but as soon as the animation triggers, and starts its expensive
>> paint, unrelated rAF timers will hitch as well.
>>
>
> I'm a bit confused. If you're painting on the main thread, any attempt to
> paint the content could cause delays in the firing some some rAF callback.
> If you're not painting on the main thread, none of this matters. Are you
> painting it on the main thread with the ability to interrupt painting to
> return to the event loop?
>
This is with painting off the main the thread, but it still matters. While
the main thread is free to fire rAF callbacks and process scroll updates,
we still need to get the resulting changes to the screen. Without a way to
indicate that the expensive content should be handled in a special way, the
painting thread cannot know that it should give the other content higher
priority and provide the painted tiles for the other content to the
compositor before the expensive content's tiles are ready (note that this
is different from what we would normally do: we usually want the compositor
to have a coherent set of tiles, so that if the page is, say, alternating
between all-red and all-green, the compositor never produces a half-red
half-green frame).
-Ali