Implement merging non-composited paint property nodes in the PACompositor.

third_party/WebKit/Source/platform/graphics/paint/PropertyTreeState.cpp

Index: third_party/WebKit/Source/platform/graphics/paint/PropertyTreeState.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/paint/PropertyTreeState.cpp b/third_party/WebKit/Source/platform/graphics/paint/PropertyTreeState.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..b25cf7b7455601b33c7c29b0bb6421ca6f7c3cc8
--- /dev/null
+++ b/third_party/WebKit/Source/platform/graphics/paint/PropertyTreeState.cpp
@@ -0,0 +1,50 @@
+// Copyright 2016 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/paint/PropertyTreeState.h"
+
+namespace blink {
+
+bool PropertyTreeState::hasDirectCompositingReasons() const {

[trchen, 2016/12/20 23:49:36]

This feels a weird place to me. IMO the concept of direct compositing reason
doesn't apply to chunks.
A chunk gets a reason not to be squashed into a previous chunk because one of
its property node cross an edge that has direct compositing reason.

For example:
<div>A</div>
<div style="transform:translateZ(0);">
    <div style="transform:translate(0,0);">B</div>
</div>

Chunk B points to no nodes that have a direct compositing reason, but chunk B
still needs to be composited separately because of the 3D parent.

For another example:
<div style="transform:translateZ(0);">
  <div style="opacity:0.5">A</div>
  <div style="opacity:0.5">B</div>
</div>

A and B both points to a directly composited transform node, but there's no
reason why they need to be composited separately.

I think the algorithm should roughly look like this:
bool shouldBeBackedSeparately(const TransformNode* a, const TransformNode* b) {
  if (depth(a) > depth(b))
    swap(a, b);
  for(;depth(b) > depth(a); b = b->parent) {
    if (b->hasDirectCompositingReason())
      return true;
  }
  for (;a != b; a = a->parent, b = b->parent)
    if (a->hasDirectCompositingReason() || b->hasDirectCompositingReason())
      return true;
  return false;
}

[chrishtr, 2016/12/20 23:58:10]

doesn't apply to chunks.

I don't have it on chunks, I have it on nodes. Also see below.
This is the algorithm I have implemented, generalized to multiple property
trees.
The method here is a convenience method to check against the innermostNode().

[trchen, 2016/12/21 00:37:11]

Ah, I see. It all makes sense now. However I feel this introduces a lot
confusion. These concepts apply to the multi-prop-tree node, where both the key
and the value is a property state. Why is it less convenient to do it as a
private impl class of PAC? Like this:

namespace {
class MultiPropTreeNode : public PropertyTreeState {
public:
  bool hasDirectCompositingReasons() const;
  InnermostNode innermostNode() const;
};
}

+  switch (innermostNode()) {
+    case Transform:
+      return transform()->hasDirectCompositingReasons();
+    case Clip:
+      return clip()->hasDirectCompositingReasons();
+    case Effect:
+      return effect()->hasDirectCompositingReasons();
+    default:
+      return false;
+  }
+}
+
+PropertyTreeState::InnermostNode PropertyTreeState::innermostNode() const {

[trchen, 2016/12/20 23:49:36]

Likewise, an imaginary combined tree of mixed types of property nodes is a
concept introduced by layerization implementation.

[chrishtr, 2016/12/20 23:58:10]

See above. I've added it on PropertyTreeState for convenience.

+  if (!m_transform->isRoot() && m_clip->localTransformSpace() != m_transform &&
+      m_effect->localTransformSpace() != m_transform)

[trchen, 2016/12/20 23:49:36]

FYI there is one corner case where the transform space of the clip may be deeper
than transform of the chunk.
<div style="position:absolute; clip:rect(1,2,3,4);">
  <div style="position:fixed;"></div>
</div>

[chrishtr, 2016/12/20 23:58:10]

In this case, the position: fixed chunk would point to the root transform node
and the clip node for the clip: rect(...) clip. The position: absolute chunk
would point to
the frame scrolling transform node and the root clip. Seems ok to me..

[trchen, 2016/12/21 00:37:11]

It seemed to me you want to guarantee that if state->innermostNode() ==
Transform, that implies
state->transform()->isDescendantOf(state->clip()->localTransformSpace()). If you
didn't want that guarantee, it is probably okay.

Another thing I worried about is the inferred total order of nodes could be
inconsistent. Consider the following tree & chunks:
T0 <- T1 <- T2
C0 <- C1(localSpace=T2)
ChunkA(T1, C1)
ChunkB(T2, C1)

The inferred total order from Chunk A would be: Root <- C1 <- T1
While the inferred order from Chunk B would be: Root <- T1 <- T2 <- C1
Fortunately today we never generate such tree because of CssClipFixedPosition
nodes, but I feel an extra DCHECK would be handy...

+    return Transform;
+  if (!m_effect->isRoot() && m_effect->outputClip() == m_clip) {
+    return Effect;
+  }
+  if (!m_clip->isRoot())
+    return Clip;
+  return None;
+}
+
+const PropertyTreeState* PropertyTreeStateIterator::next() {
+  switch (m_properties.innermostNode()) {
+    case PropertyTreeState::Transform:
+      m_properties.setTransform(m_properties.transform()->parent());
+      return &m_properties;
+    case PropertyTreeState::Clip:
+      m_properties.setClip(m_properties.clip()->parent());
+      return &m_properties;
+    case PropertyTreeState::Effect:
+      m_properties.setEffect(m_properties.effect()->parent());
+      return &m_properties;
+    case PropertyTreeState::None:
+      return nullptr;
+  }
+}
+
+}  // namespace blink