- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Mon, 6 Feb 2012 14:40:07 -0500
- To: Dean Jackson <dino@apple.com>, Simon Fraser <smfr@me.com>
- Cc: David Hyatt <hyatt@apple.com>, Chris Marrin <cmarrin@apple.com>, "Edward O'Connor" <eoconnor@apple.com>, Vincent Hardy <vhardy@adobe.com>, Dirk Schulze <dschulze@adobe.com>, www-style@w3.org, Matt Woodrow <mwoodrow@mozilla.com>
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) > 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? 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. 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?
Received on Monday, 6 February 2012 19:40:59 UTC