W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2016

Re: [css-transforms] CSS3D breaks with opacity flattening

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 22 Sep 2016 10:00:18 +0100
Message-ID: <CAGN7qDCnF89soJzZPrjmORzWF5+sA4y7HYXo0dYp=KPO2Z2Mag@mail.gmail.com>
To: Tien-Ren Chen <trchen@chromium.org>
Cc: Matt Woodrow <mwoodrow@mozilla.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "/#!/JoePea" <trusktr@gmail.com>, Chris Harrelson <chrishtr@google.com>, Simon Fraser <simon.fraser@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
On Thu, Sep 22, 2016 at 8:44 AM, Tien-Ren Chen <trchen@chromium.org> wrote:

> On Wed, Sep 21, 2016 at 6:28 PM, Matt Woodrow <mwoodrow@mozilla.com>
> wrote:
> > On 22/09/16 12:41 PM, Tien-Ren Chen wrote:
> >>
> >> I don't think group opacity can be properly defined without
> >> flattening. What if some planes in the group are non-opaque themselves
> >> and later intersect with non-opaque planes outside of the group?
> >>
> >> Specifically, how would you define the expected behavior for this
> >> particular example? http://jsbin.com/tepixi/
> >>
> > Right, I totally agree with this.
> >
> > Opacity *does* require flattening, and if there are planes outsides the
> > group that want to be sorted with planes within the group, there isn't a
> way
> > to properly define behaviour.
> >
> > My point is that when we do the flattening for opacity, we should do so
> in
> > the coordinate space of the root element of the preserve-3d context (by
> > propagating ancestors transforms down through the opacity), since this
> > results in better rendering for the cases where sorting across the
> opacity
> > boundary isn't required (and there *is* a reasonable definition for the
> > right behaviour).
>
> In Chromium's new rendering model we internally see flattening as a
> combo of two operations:
> A. Modify the accumulated matrix so that the depth of inner 3D context
> will be propagated to screen space intact.
> B. A grouping property that performs depth sorting on planes collected
> so far, and output as an atomic group (i.e. child stacking context).
> The depth component of the output will be applied using the current
> accumulated matrix.
>
> Let me try to rephrase your approach, basically you want
> transform-style:preserve-3d + opacity to perform just operation B but
> not operation A. For example:
>
> <style> div { transform-style: preserve-3d; } </style>
> <div style="perspective:1000px;">
>   <div style="transform:rotateX(-20deg);">
>     <div style="opacity:0.7; background:rgba(255,0,0,0.7);
> transform:rotateY(45deg);" >
>       <div style="background:rgba(0,255,0,0.7);
> transform:rotateY(-90deg);"></div>
>     </div>
>     <div style="background:rgba(0,0,255,0.7);
> transform:translateZ(30px);"></div>
>   </div>
> </div>
>
> Should render equivalent to:
>
> <style> div { transform-style: preserve-3d; } </style>
> <div style="perspective:1000px;">
>   <div style="transform:rotateX(-20deg);">
>     <div style="transform-style:flat; opacity: 0.7;
> transform:rotateY(45deg)matrix3d(1.4142131, 0.36397033, 0.0,
> -0.0010641774, 0.0, 1.0641773, 0.0, -0.00036396993, 0.0, 0.0, 1.0,
> 0.0, 0.0, 0.0, 0.0, 1.0);">
>       <div style="transform:perspective(1000px)rotateX(-20deg);">
>         <div class="grid" style="background:rgba(255,0,0,0.7);
> transform:rotateY(45deg);" >
>           <div class="grid" style="background:rgba(0,255,0,0.7);
> transform:rotateY(-90deg);"></div>
>         </div>
>       </div>
>     </div>
>     <div class="grid" style="background:rgba(0,0,255,0.7);
> transform:translateZ(30px);"></div>
>   </div>
> </div>
>
> Where the matrix3d(...) just undo the 2D part of the accumulated
> matrix. i.e. matrix3d(...) =
> flatten(perspective(1000px)rotateX(-20deg)rotateY(45deg))^-1
> So that preserve-3d + opacity will propagate the accumulated matrix to
> its descendants, and its descendants will perform depth sorting with
> total matrix. The result will be projected back to the plane that has
> the opacity property.
>
> http://jsbin.com/huveseq/ (Note: written in TR spec. Only tested on
> Chrome! See attached PNG for expected rendering.) demonstrates this
> proposal. I think I've seen this approach with a certain vendor in
> some weird corner case. However IMO this definition is not very
> useful... It is hard to understand intuitively, not backward
> compatible, and doesn't solve the use case /#!/JoePea have.


I think you just showed that Matt's proposal can be emulated with the
current spec.

Given that:

   - this is shipping in Chrome [1]
   - Safari committed to support it [2]
   - Edge is in favor  [3]
   - Firefox has already implemented it [4]
   - your new proposal is more complex to implement and hard to understand
   - your new proposal can be emulated

I see little reason to change.

1: https://www.chromestatus.com/features/5671480339726336
2: https://lists.w3.org/Archives/Public/www-style/2016Feb/0311.html https://
logs.csswg.org/irc.w3.org/css/2016-06-08/#e696550
3: https://logs.csswg.org/irc.w3.org/css/2016-06-08/#e696537
4: https://bugzilla.mozilla.org/show_bug.cgi?id=1283827


> > For cases like yours, there is no right behaviour, so we're just picking
> > which fallback sucks the least.
> >
> > - Matt
> >
> >
> >
>
Received on Thursday, 22 September 2016 09:00:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:57 UTC