Re: SVG Compositing + 3D Transform

It seems that if there is a comp-op, preserve-3d should be false.
It doesn't make much sense to do compositing in 3-d. The end result of a
comp-op should always be a 2D image.

Rik

On Mon, May 16, 2011 at 3:03 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Mon, May 16, 2011 at 7:19 PM, Dirk Schulze <vbs85@gmx.de> wrote:
>
>> I have a short question about combining the new specifications 3D
>> Transform and Compositing (and maybe z-index as well). Isn't it possible
>> that the source graphic could be placed behind the destination graphic with
>> 3D Transforms? How would that influence the compositing of both graphics?
>>
>
> First of all, let me note that 'comp-op' applied to non-SVG content needs
> to induce a CSS psuedo-stacking-context as 'opacity', 'filter' and other
> group compositing operations do, to ensure that the element can be rendered
> as an atomic unit (without having its parents interleaved with the parts of
> other elements in z-order).
>
> Then, your issue isn't a problem for z-index or 3D transforms without
> preserve-3d. In those cases, elements and their parts can be rendered one by
> one onto the destination canvas, in the order defined by CSS z-index. When
> you need to render an element with 'comp-op', the contents of the background
> are clearly defined and so is the result of the comp-op.
>
> With preserve-3d though, there might be an issue, depending on whether
> depth buffering is supposed to be used. I believe the spec there is still
> unclear. If depth buffering is used then it's not clear what comp-op should
> do.
>
> Rob
> --
> "Now the Bereans were of more noble character than the Thessalonians, for
> they received the message with great eagerness and examined the Scriptures
> every day to see if what Paul said was true." [Acts 17:11]
>