W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css-shaders] subdivision for transparency

From: James Robinson <jamesr@google.com>
Date: Mon, 3 Oct 2011 21:04:22 -0700
Message-ID: <CAD73mdKZ-QYv1kABjxJEHSm9d9nEetOPs+O=G5oLb6aZ5+Mf-A@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: Gregg Tavares <gman@google.com>, www-style list <www-style@w3.org>
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>
Received on Tuesday, 4 October 2011 04:05:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:50 UTC