W3C home > Mailing lists > Public > www-style@w3.org > May 2013

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

From: Simon Fraser <smfr@me.com>
Date: Thu, 23 May 2013 11:43:34 -0700
Cc: Ali Juma <ajuma@chromium.org>, Robert O'Callahan <robert@ocallahan.org>, www-style <www-style@w3.org>, Jon Rimmer <jon.rimmer@gmail.com>, Ian Vollick <vollick@chromium.org>
Message-id: <F9416AA0-79C9-404B-97BE-2A14091CB039@me.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On May 23, 2013, at 11:40 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, May 23, 2013 at 11:34 AM, Simon Fraser <smfr@me.com> wrote:
>> 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.
> 
> It's entirely consistent with Blink's compositor architecture (given
> that it was some Blink compositor people who asked me about it).
> 
> I'm not sure how different other browsers' compositor architectures
> are, but I wouldn't think they'd be *that* different, such that doing
> something like this is impossible.
> 
> Note that this doesnt' involve render-tree work - the render tree is
> already constructed and done.  It's expensive *painting* that's the
> issue.

But each paint represents a particular state of the render tree. The request
seems to imply that you want to queue up an expensive paint earlier than
a cheap paint, so they can be done at the same time. That then implies that
you’re able to generate the render state for the expensive paint independently,
which is the hard part.

Simon



Received on Thursday, 23 May 2013 18:44:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC