Re: [css-shaders] subdivision for transparency

On Mon, Oct 3, 2011 at 8:18 PM, Dean Jackson <dino@apple.com> wrote:

>
> On 04/10/2011, at 11:10 AM, Gregg Tavares (wrk) wrote:
>
> Looking at the CSS shader proposal I wonder what if any story there is
> about subdivision of polygons to correctly display content.
>
> The current 3D CSS spec does not list subdivision as far as I know but
> Safari implemented it first and as the implied reference implementation it
> subdivides polygons where necessary. Chrome currently does not.
>
>
> It's unfortunate that the specification does not describe what to do here.
> In fact, that was deliberate at the time because we didn't know what was
> best. Safari originally did not subdivide the polygons, and still doesn't on
> OS X 10.5. The fact that we do now isn't really something we specify (even
> at a platform level)
>
> What do I mean? Well, in order to correctly display 2 or more
> semi-trasparent elements that intersect each other in 3d space it's
> necessary to subdivide the polygons that are used to draw the elements with
> so that the part of the elements that are behind others are drawn first,
> then the parts in front are drawn last.
>
> Here are 2 screenshots. The first shows Safari which correctly subdivides
> the polygons. The second shows Chrome which currently does not.
>
> <correct-3d-css-polygon-sorting-subdivisions-safari.png>
> <incorrect-3d-css-polygon-sorting-subdivisions-chrome.png>
>
> Arguably Chrome should update its renderer to handle this case so that web
> developers can count on correct displaying of 3d css content.
>
>
>
> But, that brings up the question, that's the sorting spec going to be for
> CSS shaders?
>
>
> I'm not sure I understand the question completely. CSS filters (let's not
> call them shaders - that's just a proposed extension to the current draft)
> are always a 2d effect, even if they appear 3d. In other words, the effect
> might operate locally in a 3d or pseudo-3d environment, but the result is
> always composited in 2d onto a flat plane. Elements should sort the way they
> do for regular HTML (with CSS 3D transforms, which is probably
> less-than-well-defined). A filter does not make an element 3d.
>

I think saying that this behavior for CSS 3D transforms
less-than-well-defined is a bit of an understatement.  The question is
completely ignored by the CSS 3D transforms spec and implementations have
imperfectly reverse-engineered each other.  Since CSS 3D transforms can only
manipulate quads we've been able to sort-of skate by with this behavior
being unspecified. but if we expect to have more complex geometries (which
is a key motivation for having filters on vertices) then I think we have to
actually specify a behavior or this will just be a giant mess.

* What is the behavior of the Z coordinate of gl_Position in my vertex
shader if the element being filtered shared a transform-style: preserve-3d
ancestor with another element that has a Z transform set?
* What is the behavior for two elements that set different Z coordinates
that share a transform-style: preserve-3d ancestors?

Without answering this question in some concrete form I think the proposal
is really hard to evaluate.

- James


> Dean
>
>
>
>
> ps: the live html/css is here
> http://greggman.com/downloads/examples/intersecting-elements-3d-css.html
>
> pps: if you care about Chrome status on this issue you can follow it here<http://code.google.com/p/chromium/issues/detail?id=74204>
>
>
>
>