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

Re: [css-compositing] new Editor's draft posted -> update

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 23 May 2013 17:10:55 -0700
Message-ID: <CAGN7qDCn0AFCMtFbXzX+iLpukTN0LPzwm__nSTmgcZu4TfL8LA@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>, www-style list <www-style@w3.org>, www-svg <www-svg@w3.org>, David Baron <dbaron@dbaron.org>, "Robert O'Callahan" <robert@ocallahan.org>
On Thu, May 23, 2013 at 4:57 PM, James Robinson <jamesr@google.com> wrote:

> On Thu, May 23, 2013 at 4:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> After talking this over with our engineers, it turns out that the
>> invisible 'layers' that browsers create, are not actually a problem.
>> This is because they are composited in order and not as a tree (at least
>> on webkit and blink).
>> For instance, if you have content like this:
>> <video>...</video>
>> <div>
>> <p>...</p>
>> <p style="mix-blend-mode">...
>> there will be 3 layers on the back-end: one for video, one for the <div>
>> and for the <p> with the blending.
>> This content will be composited as a list so <p> will composite and blend
>> with the composited result of <video> + <div> which is the desired behavior.
> Well no, it depends.  Sometimes it will render in the way you say here,
> but sometimes we may blend the <p> together with the <div> before blending
> that with the <video> or we may put different subsets of these layers into
> separate intermediate surfaces.  We may be forced to blend the <div> and
> the <p> together without involving the <video>'s contents if the <div> has
> a transform-style: preserve3D, for example.

Yes, that is why the <p> should become a stacking context and a composited
layer (in WK/blink terms). 'mix-blend-mode' acts like opacity and can
probably build on that behavior.

If <div> has a 'transform-style', it becomes another stacking context. At
that point it is expected that the <p> no longer blends with the <video>

> Whether this produces any observable difference in the final output
> depends on exactly why you are depending on the draw order - in general,
> you really shouldn't.

Blending does depend on draw order. It doesn't have that nice associative
behavior you get with alpha compositing.
In reality, the textures are drawn by the openGL blender at the very end
and in-order. If we implement this in blink, we will need to be very
careful to preserve this. (Brian Salomon is already doing this.)

>> I updated the spec and removed that particular issue. I also worded it so
>> blending will happen between stacking context (which is what David Baron
>> suggested in an earlier email)
>> There will still be work needed on the implementation side to plumb this
>> i, but I think this will suffice for the specification.
>> Rik
Received on Friday, 24 May 2013 00:11:28 UTC

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