Last Comment Bug 724025 - transform-style: flat behavior does not seem to match WebKit or spec
: transform-style: flat behavior does not seem to match WebKit or spec
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: mozilla13
Assigned To: Matt Woodrow (:mattwoodrow)
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-03 10:34 PST by Aryeh Gregor (:ayg) (away until October 25)
Modified: 2012-02-15 09:18 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix transform-style:flat with BasicLayers (3.12 KB, patch)
2012-02-05 18:12 PST, Matt Woodrow (:mattwoodrow)
roc: review+
Details | Diff | Splinter Review

Description Aryeh Gregor (:ayg) (away until October 25) 2012-02-03 10:34:20 PST
The behavior of preserve-3d is now described in some detail in the latest spec, which was somewhat rewritten:

http://dev.w3.org/csswg/css3-transforms/#transform-3d-rendering

Excerpt:

"""
An element with a three-dimensional transform that is not contained in a 3D rendering context renders with the appropriate transform applied, but does not intersect with any other elements. The three-dimensional transform in this case can be considered just as a painting effect, like two-dimensional transforms. Similarly, the transform does not affect painting order. For example, a transform with a positive Z translation may make an element look larger, but does not cause that element to render in front of elements with no translation in Z.

An element with a three-dimensional transform that is contained in a 3D rendering context can visibly interact with other elements in that same 3D rendering context; the set of elements participating in the same 3D rendering context may obscure each other or intersect, based on their computed transforms. They are rendered as if they are all siblings, positioned in a common 3D coordinate space. The position of each element in that three-dimensional space is determined by accumulating the transformation matrices up from the element that establishes the 3D rendering context through each element that is a containing block for the given element, as described below.
"""

This is still pretty vague, but there's an example that clarifies a bit.  The idea seems to be that if 'transform-style' is "flat", the first child is rendered, then the second is painted on top, and so on.  Moreover, each child's children are painted within it before any transforms are applied.  So for instance:

data:text/html,<!doctype html>
<div style="-moz-transform:rotatex(45deg)">
<div style="-moz-transform:rotatex(-45deg);
height:100px;width:100px;background:lime">

In Firefox 13.0a1 (2012-02-01), the two transforms cancel out, and you get a square.  But in Chrome 18 dev, they don't: you get a rectangle, wider than it is tall.  Basically, when the second div is rendered, it's projected onto the plane of its parent, so it just gets shortened twice.  The effect is identical if you replace -45deg with 45deg, because either one foreshortens vertically by 1/sqrt(2).  Really I guess it's logically like applying scalez(0) to it at each step, except in Gecko that makes stuff disappear (bug 719092).

The spec is a bit vague, but seems to match how Chrome behaves.  Would it be helpful if I wrote clearer spec text, and/or lots of test-cases?  I plan to write lots of test-cases in any event.
Comment 1 Aryeh Gregor (:ayg) (away until October 25) 2012-02-03 10:38:13 PST
Another oddity:

data:text/html,<!doctype html>
<div style="-moz-transform:rotatex(89deg)">
<div style="-moz-transform:rotatex(-89deg);
height:100px;width:100px;background:lime">

is still a square, but

data:text/html,<!doctype html>
<div style="-moz-transform:rotatex(90deg)">
<div style="-moz-transform:rotatex(-90deg);
height:100px;width:100px;background:lime">

vanishes (see layout/reftests/transform-3d/preserve3d-1b.html).
Comment 2 Aryeh Gregor (:ayg) (away until October 25) 2012-02-03 11:33:34 PST
Here are a few test-cases.  All should be green squares (with scrollbars on the last one), and they are in IE10 Developer Preview and Chrome 18 dev, but not in Firefox 13.0a1:

data:text/html,<!doctype html>
<div style="-moz-transform: rotatex(45deg); -moz-transform-origin: top">
<div style="-moz-transform: rotatex(-45deg); -moz-transform-origin: top;
height: 200px; width: 100px; background: lime">
</div></div>

data:text/html,<!doctype html>
<div style="-moz-transform: rotatey(45deg); -moz-transform-origin: left">
<div style="-moz-transform: rotatey(-45deg); -moz-transform-origin: left;
height: 100px; width: 200px; background: lime">
</div></div>

data:text/html,<!doctype html>
<div style="-moz-transform: rotatex(45deg); -moz-transform-origin: top;
-moz-transform-style: preserve-3d; overflow: hidden">
<div style="-moz-transform: rotatex(-45deg); -moz-transform-origin: top;
height: 200px; width: 100px; background: lime">
</div></div>

data:text/html,<!doctype html>
<div style="-moz-transform: rotatex(45deg); -moz-transform-origin: top;
-moz-transform-style: preserve-3d; overflow: auto">
<div style="-moz-transform: rotatex(-45deg); -moz-transform-origin: top;
height: 200px; width: 100px; background: lime">
</div></div>

data:text/html,<!doctype html>
<div style="-moz-transform: rotatex(45deg); -moz-transform-origin: top;
-moz-transform-style: preserve-3d; overflow: scroll">
<div style="-moz-transform: rotatex(-45deg); -moz-transform-origin: top;
height: 200px; width: 100px; background: lime">
</div></div>
Comment 3 Matt Woodrow (:mattwoodrow) 2012-02-05 18:12:19 PST
Created attachment 594610 [details] [diff] [review]
Fix transform-style:flat with BasicLayers
Comment 4 Aryeh Gregor (:ayg) (away until October 25) 2012-02-06 12:06:20 PST
FWIW, transform-style: flat behavior doesn't make sense to me, and so far it seems to me 3D transforms would be much improved by removing it and make everything preserve-3d:

http://lists.w3.org/Archives/Public/www-style/2012Feb/0291.html
Comment 5 Mozilla RelEng Bot 2012-02-07 14:28:19 PST
Autoland Patchset:
	Patches: 594610
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/rev/101d44cbae8c
Try run started, revision 101d44cbae8c. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=101d44cbae8c
Comment 6 Mozilla RelEng Bot 2012-02-08 02:30:23 PST
Try run for 101d44cbae8c is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=101d44cbae8c
Results (out of 212 total builds):
    success: 196
    warnings: 16
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-101d44cbae8c
 Timed out after 06 hours without completing.
Comment 7 Matt Woodrow (:mattwoodrow) 2012-02-15 01:30:17 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/3884d70d2f7d
Comment 8 Marco Bonardo [::mak] 2012-02-15 09:18:47 PST
https://hg.mozilla.org/mozilla-central/rev/3884d70d2f7d

Note You need to log in before you can comment on or make changes to this bug.