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

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

 // 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.
 
 #include "platform/graphics/compositing/PaintArtifactCompositor.h"
 
 #include "cc/layers/content_layer_client.h"
 #include "cc/layers/layer.h"
 #include "cc/layers/picture_layer.h"
 #include "cc/playback/display_item_list.h"
@@ skipping 374 matching lines @@
     compositorNode.source_node_id = parentId;
 
     FloatPoint3D origin = transformNode->origin();
     compositorNode.pre_local.matrix().setTranslate(
         -origin.x(), -origin.y(), -origin.z());
     compositorNode.local.matrix() = TransformationMatrix::toSkMatrix44(transformNode->matrix());
     compositorNode.post_local.matrix().setTranslate(
         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);
     dummyLayer->SetEffectTreeIndex(kSecondaryRootNodeId);
     dummyLayer->SetScrollTreeIndex(kRealRootNodeId);
     dummyLayer->set_property_tree_sequence_number(kPropertyTreeSequenceNumber);
 
     auto result = m_transformNodeMap.set(transformNode, id);
     DCHECK(result.isNewEntry);
     transformTree().set_needs_update(true);
@@ skipping 63 matching lines @@
 
         layer->set_offset_to_transform_parent(layerOffset);
 
         m_rootLayer->AddChild(layer);
         layer->set_property_tree_sequence_number(kPropertyTreeSequenceNumber);
         layer->SetTransformTreeIndex(transformId);
         layer->SetClipTreeIndex(clipId);
         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);
     }
 
     // Mark the property trees as having been rebuilt.
     host->property_trees()->sequence_number = kPropertyTreeSequenceNumber;
     host->property_trees()->needs_rebuild = false;
 }
 
 } // namespace blink