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

On Mon, Sep 19, 2016 at 12:58 PM, Nexii Malthus <nexiim@gmail.com> wrote:

> It's been a while since I have done 3d graphics programming, but isn't
> this solvable as a 'render to texture' - a simple technique that dates back
> to very early 3d game graphics? This should preserve-3d on the car frame
> for the internal 3d perspective, no?
>
Yes, that is what the current spec says and what is implemented in Chrome.

> You could even use a simple pixel shader of you fancied having depth still
> working.
>
> On Mon, 19 Sep 2016 9:41 am Rik Cabanier, <cabanier@gmail.com> wrote:
>
>> On Mon, Sep 19, 2016 at 8:22 AM, Matt Woodrow <mwoodrow@mozilla.com>
>> wrote:
>>
>>> On 19/09/16 6:27 PM, Tab Atkins Jr. wrote:
>>>
>>>> No, as I explained in more detail in the GitHub thread I linked
>>>> <https://github.com/w3c/svgwg/issues/264#issuecomment-246750601>, this
>>>> is a logical consequence of 'opacity' and other filter-type effects
>>>> being "group effects".  If you want the effect to only apply to the
>>>> leaves, you can do that yourself by specifying it on the leaves, but
>>>> it has a visibly different effect than doing it "as a group".
>>>>
>>> Sorry, I'm not quite sure I follow. The idea I proposed explicitly
>>> *doesn't* break the group nature of opacity, which is why I think it's
>>> worth discussing.
>>>
>>> The example I gave had opacity applied to an intermediate element, and
>>> showed the internal representation needed to apply it as a group while
>>> maintaining preserve-3d.
>>>
>>
>> What you're proposing will also change how content is rendered. :-\
>>
>>
>>> Are there more complex examples you can think of where this breaks down?
>>>
>>> Obviously this would prevent depth sorting occurring between elements
>>>>> inside
>>>>> and outside of 'b', and we need to figure out how to depth sort 'b'
>>>>> itself
>>>>> (given that it is an atomic entry for sorting, but isn't a 2d plane),
>>>>> but
>>>>> those seem solvable.
>>>>>
>>>> That's actually the core problem preventing this from working; it's
>>>> not a detail we can just paper over later.
>>>>
>>> Which part of this? The first piece is the exact same situation we have
>>> when we flatten for opacity, so I don't see how that's a problem. The
>>> latter is somewhat difficult from an implementation standpoint, but it's
>>> not obvious that it's a showstopper.
>>
>>
>> Why is that not a showstopper? Your proposal seems very difficult to
>> implement since it pushes matrix manipulation all the way down to the
>> individual elements.
>> It also introduces more rendering surfaces.
>> You're also relying on how firefox is representing the render tree which
>> might be completely different from other UA's
>>
>> Browsers already have a hard time giving a consistent experience with the
>> simple model and this will make it even more complicated.
>>
>