- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 23 May 2013 11:17:36 -0700
- To: Ali Juma <ajuma@chromium.org>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, www-style <www-style@w3.org>, Jon Rimmer <jon.rimmer@gmail.com>, vollick@chromium.org
On Fri, May 10, 2013 at 7:20 AM, Ali Juma <ajuma@chromium.org> wrote: > 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). Further thoughts, roc? This thread accidentally died. ^_^ ~TJ
Received on Thursday, 23 May 2013 18:18:28 UTC