On May 23, 2013, at 11:17 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > 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. ^_^ The feature request (allow the engine to prepare “expensive to render” content in one RAF while servicing cheaply painted stuff in other RAFs seems contrary to the way that browsers layout and render. Speaking for WebKit at least, we can’t be working on one part of the render tree “in the background” while doing other layouts and renders. Simon
Received on Thursday, 23 May 2013 18:35:00 UTC