[SPv2] Respect transform-style in the Blink and cc property trees.

third_party/WebKit/Source/platform/graphics/paint/TransformPaintPropertyNode.h

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef TransformPaintPropertyNode_h
 #define TransformPaintPropertyNode_h
 
 #include "platform/PlatformExport.h"
 #include "platform/geometry/FloatPoint3D.h"
 #include "platform/transforms/TransformationMatrix.h"
 #include "wtf/PassRefPtr.h"
 #include "wtf/RefCounted.h"
 #include "wtf/RefPtr.h"
 
 #include <iosfwd>
 
 namespace blink {
 
 // A transform created by a css property such as "transform" or "perspective"
 // along with a reference to the parent TransformPaintPropertyNode, or nullptr
 // for the root.
 class PLATFORM_EXPORT TransformPaintPropertyNode : public RefCounted<TransformPaintPropertyNode> {
 public:
-    static PassRefPtr<TransformPaintPropertyNode> create(const TransformationMatrix& matrix, const FloatPoint3D& origin, PassRefPtr<TransformPaintPropertyNode> parent = nullptr)
+    enum TransformStyle { FlattenTransform, Preserve3D };
+    enum RenderingContextBehavior {

[trchen, 2016/07/13 04:39:44]

I don't think this belong here. This is a CSS concept that should not leak into
platform layer.

The sole purpose of it is to resolve rendering context root. why don't we
resolve it in the PropertyTreeBuilder?

[jbroman, 2016/07/13 21:47:13]

Because the |this| pointer doesn't exist yet there (until the |new| operator),
so I cannot provide it. (And I cannot use |nullptr| as a placeholder for it,
because that causes the perspective issue you pointed out.)

[trchen, 2016/07/13 22:31:42]

Why do we need to TransformPaintPropertyNode* as sorting context id? Can't we
generate a serial number in PaintPropertyTreeBuilder?

[jbroman, 2016/07/14 20:34:58]

It doesn't need to be; it just was (it's convenient for debugging, though).
Changed to have PaintPropertyTreeBuilder assign one.

+        // The node should participate in the context provided, if any, but not
+        // establish a new one.
+        DontEstablishNewRenderingContext,
+
+        // The node should establish a new 3D rendering context.
+        // No existing rendering context root should be provided.
+        EstablishNewRenderingContext
+    };
+
+    // Creates a transform node, allowing full specification of the rendering
+    // context and transform style. If renderingContextBehavior is
+    // EstablishNewRenderingContext, then the renderingContextRoot provided must
+    // be null.
+    static PassRefPtr<TransformPaintPropertyNode> create(
+        const TransformationMatrix& matrix,
+        const FloatPoint3D& origin,
+        PassRefPtr<TransformPaintPropertyNode> parent,
+        RenderingContextBehavior renderingContextBehavior,
+        const TransformPaintPropertyNode* renderingContextRoot,
+        TransformStyle transformStyle)
     {
-        return adoptRef(new TransformPaintPropertyNode(matrix, origin, parent));
+        return adoptRef(new TransformPaintPropertyNode(matrix, origin, parent, renderingContextBehavior, renderingContextRoot, transformStyle));
+    }
+
+    // As above, but inherits the rendering context and transform style from the
+    // parent transform node. Never establishes a new rendering context.
+    static PassRefPtr<TransformPaintPropertyNode> create(
+        const TransformationMatrix& matrix,
+        const FloatPoint3D& origin,
+        PassRefPtr<TransformPaintPropertyNode> parent = nullptr)
+    {
+        if (!parent)
+            return create(matrix, origin, nullptr, DontEstablishNewRenderingContext, nullptr, FlattenTransform);
+
+        // Have to copy the data out of parent before we pass the reference
+        // (and null out the local pointer).
+        const TransformPaintPropertyNode* renderingContextRoot = parent->renderingContextRoot();
+        TransformStyle transformStyle = parent->transformStyle();
+        return create(matrix, origin, parent, DontEstablishNewRenderingContext, renderingContextRoot, transformStyle);
     }
 
     const TransformationMatrix& matrix() const { return m_matrix; }
     const FloatPoint3D& origin() const { return m_origin; }
 
     // Parent transform that this transform is relative to, or nullptr if this
     // is the root transform.
     TransformPaintPropertyNode* parent() const { return m_parent.get(); }
 
+    // Content whose transform nodes have a common rendering context root is 3D
+    // sorted. If this is nullptr, content will not be 3D sorted.
+    const TransformPaintPropertyNode* renderingContextRoot() const { return m_renderingContextRoot; }
+    bool hasRenderingContext() const { return renderingContextRoot(); }
+
+    // If a transform node flattens transform, then content within it is
+    // flattened into the plane of the transform space (including this node's
+    // matrix). If it preserves 3D, then no such flattening occurs.
+    //
+    // This corresponds fairly closely to CSS transform-style semantics, and in
+    // CSS is fairly tightly connected with the rendering context root.
+    TransformStyle transformStyle() const { return m_transformStyle; }
+    bool flattensTransform() const { return transformStyle() == FlattenTransform; }
+    bool preserves3D() const { return transformStyle() == Preserve3D; }

[trchen, 2016/07/13 04:39:44]

Ditto. It is a leak of CSS concept. I think flattensInheritedTransform is more
accurate.

We don't flatten contents in the subtree into the plane. If the contents flatten
into a plane then how can we perform depth sorting on them? It is the opposite.
We flatten the inherited transform so the depth information is preserved, but
won't become an input to the inherited transform.

[chrishtr, 2016/07/13 20:30:50]

I don't understand this comment, could you rephrase or given an example? Also,
you mentioned "inherited transform" twice but they seem to refer to different
things, no?

[jbroman, 2016/07/13 21:47:13]

This isn't the CSS concept, because it is not intertwined with rendering
contexts anymore; PaintPropertyTreeBuilder makes that separation.

It's essentially "flattens inherited transform", except that it's off-by-one;
PaintArtifactCompositor makes the translation. cc's flattens_inherited_transform
means that the transform applied due to ancestor nodes is flattened before it
applies to this node. This "flattens transform / preserves 3D" (perhaps I could
rename the latter, if it's confusing, but here I mean "preserves the
non-flat-ness", not "preserves the 3D rendering context") means that the
transform due to ancestor nodes _and this node_ is flattened before it applies
to descendants.

[trchen, 2016/07/13 22:31:42]

In that case, why not name it "flattensLocalToScreenTransform"? I still don't
know why we need to introduce a similar but different semantics. Can't we
resolve it to cc semantics in PropertyTreeBuilder?

[trchen, 2016/07/13 22:31:42]

For example:

<div style="transform-style:preserve-3d;">
  <div style="transform:rotateX(10deg);">
    <div style="transform-style:preserve-3d;">
      <div style="transform:rotateY(10deg);">A</div>
      <div style="transform:rotateY(-10deg);">B</div>
    </div>
  </div>
</div>

It's not that we flatten A and B to the flattening plane. That way the
local-to-screen transform would be:
A.local_to_screen = rotateX(10deg) * flatten(rotateY(10deg))
B.local_to_screen = rotateX(10deg) * flatten(rotateY(-10deg))

They will be co-planar (to the plane that created 3D context) thus can't perform
depth sorting.

In fact what happened was that the inherited transform getting flattened, so:
A.local_to_screen = flatten(rotateX(10deg)) * rotateY(10deg)
B.local_to_screen = flatten(rotateX(10deg)) * rotateY(-10deg)
which is equivalent to
A.local_to_screen = scaleY(0.985) * rotateY(10deg)
B.local_to_screen = scaleY(0.985) * rotateY(-10deg)

The term "flatten inherited transform" makes sense in the context of computing
local-to-screen matrix of a transform node. Basically:
this->local_to_screen = (this->flatten_Inherited_transform ?
flatten(parent->local_to_screen) : parent->local_to_screen) * this->local

I agree this is a bit of counter-intuitive, but this is what Blink/WebKit does.
You'll realize its semantics is pretty clean once you get used to it.

[jbroman, 2016/07/14 20:34:58]

We can, and now this CL does. It does require some additional bookkeeping,
though (on the other hand, it arguably simplifies TransformPaintPropertyNode
itself).

+
 private:
+    TransformPaintPropertyNode(
+        const TransformationMatrix& matrix,
+        const FloatPoint3D& origin,
+        PassRefPtr<TransformPaintPropertyNode> parent,
+        RenderingContextBehavior renderingContextBehavior,
+        const TransformPaintPropertyNode* renderingContextRoot,
+        TransformStyle transformStyle)
+        : m_matrix(matrix)
+        , m_origin(origin)
+        , m_parent(parent)
+        , m_transformStyle(transformStyle)
+    {
+        switch (renderingContextBehavior) {
+        case DontEstablishNewRenderingContext:
+            m_renderingContextRoot = renderingContextRoot;
+            break;
+        case EstablishNewRenderingContext:
+            DCHECK(!renderingContextRoot);
+            m_renderingContextRoot = this;
+            break;
+        }
 
-    TransformPaintPropertyNode(const TransformationMatrix& matrix, const FloatPoint3D& origin, PassRefPtr<TransformPaintPropertyNode> parent)
-        : m_matrix(matrix), m_origin(origin), m_parent(parent) { }
+        // Every rendering context root must preserve 3D.
+        DCHECK(!m_renderingContextRoot || m_renderingContextRoot->preserves3D());
+    }
 
     const TransformationMatrix m_matrix;
     const FloatPoint3D m_origin;
     RefPtr<TransformPaintPropertyNode> m_parent;
+    const TransformPaintPropertyNode* m_renderingContextRoot;
+    const TransformStyle m_transformStyle;
 };
 
 // Redeclared here to avoid ODR issues.
 // See platform/testing/PaintPrinters.h.
 void PrintTo(const TransformPaintPropertyNode&, std::ostream*);
 
 } // namespace blink
 
 #endif // TransformPaintPropertyNode_h