Re: [css3-transforms] What is the use-case for transform-style: flat?

[Removing cc's of people who are on www-style anyway)]

On Feb 6, 2012, at 8:40 PM, Aryeh Gregor wrote:

> On Mon, Feb 6, 2012 at 2:15 PM, Dean Jackson <dino@apple.com> wrote:
>> Preserving 3D is actually a little complex (see the mozilla bugs where
>> there are some expletives trying to work out how it was implemented
>> in webkit - now Simon is writing the spec text to explain it better).
> 
> Yes, I've seen that.  It certainly made things a lot clearer.
> 
>> That's not quite true. Scaling anything to 0 doesn't really flatten it,
>> it makes it disappear.
> 
> Why?  If everything lies in the x-y plane to start with, the
> z-components are zero, so scalez(0) should be a no-op.  Why would it
> make anything disappear?  (It actually does in Firefox and IE, but not
> Chrome, at least on my machines.  But I don't know why it should.
> https://bugzilla.mozilla.org/show_bug.cgi?id=719092)

I think you are correct here; scaleZ(0) should not make elements on
the Z=0 plane disappear.

>> Also, I don't believe a scaleZ(0) would necessarily
>> take the perspective into account.
> 
> If you mean the 'perspective' property on a parent, yes, because
> scaleZ(0) will be applied after it, not before.  (That's a whole
> separate question: why do we have a separate 'perspective' property
> instead of just having authors use perspective()?  I'll start another
> thread.)
> 
>> What preserve-3d actually does under the hood is play with the nesting
>> of content - what looks like a child in the DOM might end up as a sibling
>> in the compositing engine. This has overhead that can't be turned on
>> for all transforming content.
> 
> On Mon, Feb 6, 2012 at 2:18 PM, Simon Fraser <smfr@me.com> wrote:
>> Also, in terms of implementation, UAs have to do a lot more work to support
>> the 'preserve-3d' behavior, and are likely to use more system resources doing so.
>> For this reason, we think it appropriate that authors "opt-in" to the special 3d rendering
>> context behavior, and the new rendering behaviors and potential resource usage
>> that goes along with it.
> 
> 
> So if this is just for performance considerations, can we think of
> some way to do it that doesn't require explicit author opt-in?

But it's not just for performance. The 3D rendering model, as
described in the section of the spec that describes the notion of 
3D rendering contexts, brings in a number behaviors which
are very different to the existing 2D rendering model, and potentially
confusing for authors, for example intersection, and different front-to-
back rendering order. It seems logical that the author should opt-in
to this behavior by using preserve-3d.

I also think that in many cases authors won't need to use preserve-3d
at all. If all you need is a single element which looks like it's receding
towards the horizon, you can do that with transform: perpsective(500px) rotateY(45deg).
You only need to start using preserve-3d if you're building "3d models"
by transforming elements in a hierarchy.

> For
> instance, if the only available mode were transform-style:
> preserve-3d, couldn't you optimize rendering by only enabling it if
> there's a combination of 3D transforms that needs it?  E.g., if an
> element has no 3D transform applied to it and it has at most one child
> that's being rendered, or if it has a 3D transform applied to it but
> its children have no 3D transforms applied to them, there should be no
> difference between flat and preserve-3d, so you can automatically
> switch to the faster way of doing things.

Sure, optimizations are always possible, but preserve-3d isn't primarily
about performance.
> 
> I'm concerned about the possibility that we're adding a confusing
> switch here forever for the sake of performance now.  This doesn't
> sound like a good tradeoff to me.  If I were an author, I'd do * {
> transform-style: preserve-3d } as soon as I hit the first surprising
> behavior.  Can't this be optimized without author opt-in?
> 
> I'd especially like to hear from Microsoft and Mozilla people about
> whether they agree that the performance impact requires a separate
> mode for preserve-3d.
> 
> On Mon, Feb 6, 2012 at 2:18 PM, Simon Fraser <smfr@me.com> wrote:
>> We chose 'flat' as the default because 'preserve-3d' introduces new behavior
>> which can affect elements which don't have transforms applied to them directly,
>> namely, it enables intersection of sibling elements if one of them has a transform that
>> causes it to intersect the z=0 plane.
> 
> Is this relevant if there are no 3D transforms in effect?  What's a
> case where this would be surprising to authors?


preserve-3d has no visible effect if there are no 3d transforms on elements
beneath the element with preserve-3d.

Simon

Received on Monday, 6 February 2012 19:59:48 UTC