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

third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp

Index: third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp b/third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp
index 7f85e9e41bada787a6089cace5c8d3f2af7c6881..249dac4595d32abaaf0a98e3273953b6e1c6e8c4 100644
--- a/third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp
+++ b/third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp
@@ -392,6 +392,15 @@ int PropertyTreeManager::compositorIdForTransformNode(const TransformPaintProper
         origin.x(), origin.y(), origin.z());
     compositorNode.needs_local_transform_update = true;
 
+    // cc's notion of flattening and Blink's differ based on whether they apply

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

Why is there such a difference? Is there something stopping us from adopting
cc'd semantics now?

[chrishtr, 2016/07/13 20:32:44]

Sorry, mean to say "adopting cc's semantics".

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

We cannot adopt cc's semantics in CSS (because they are web-exposed).

That leaves us lowering them either in PaintPropertyTreeBuilder or
PaintArtifactCompositor, both of which do some amount of conversion from
CSS-like semantics to cc-like semantics. The CSS-like semantics seemed more
natural to me (IIUC cc describes it the way it does because of how it computes
total transforms, top-down), but we could have TransformPaintPropertyNode be
more cc-like in this regard, at the cost of some additional bookkeeping.

+    // before or after the local transform.
+    compositorNode.flattens_inherited_transform =
+        transformNode->parent() ? transformNode->parent()->flattensTransform() : true;

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

I'd rather avoid this ambiguity. A transform node either flattens, or apply a
local matrix, but not both.

If performance is a concern so the node need to multiplex, please resolve it in
PaintPropertyTreeBuilder than here.

+
+    const TransformPaintPropertyNode* renderingContextRoot = transformNode->renderingContextRoot();
+    compositorNode.sorting_context_id =
+        renderingContextRoot ? PtrHash<const TransformPaintPropertyNode>::hash(renderingContextRoot) : 0;
+
     m_rootLayer->AddChild(dummyLayer);
     dummyLayer->SetTransformTreeIndex(id);
     dummyLayer->SetClipTreeIndex(kSecondaryRootNodeId);
@@ -475,6 +484,10 @@ void PaintArtifactCompositor::updateInLayerListMode(const PaintArtifact& paintAr
         layer->SetEffectTreeIndex(kSecondaryRootNodeId);
         layer->SetScrollTreeIndex(kRealRootNodeId);
 
+        // TODO(jbroman): This probably shouldn't be necessary, but it is still
+        // queried by RenderSurfaceImpl.
+        layer->Set3dSortingContextId(host->property_trees()->transform_tree.Node(transformId)->sorting_context_id);
+
         if (m_extraDataForTestingEnabled)
             m_extraDataForTesting->contentLayers.append(layer);
     }