Initial scroll-blocks-on compositor integration

Source/core/rendering/RenderBox.cpp

Index: Source/core/rendering/RenderBox.cpp
diff --git a/Source/core/rendering/RenderBox.cpp b/Source/core/rendering/RenderBox.cpp
index 733d523fc6b7770c3fc16527f2b404a9aa31fb97..59752828bf9457603d0f1907dbc997f27e42c613 100644
--- a/Source/core/rendering/RenderBox.cpp
+++ b/Source/core/rendering/RenderBox.cpp
@@ -102,6 +102,25 @@ RenderBox::RenderBox(ContainerNode* node)
     setIsBox();
 }
 
+LayerType RenderBox::layerTypeRequired() const
+{
+    // hasAutoZIndex only returns true if the element is positioned or a flex-item since
+    // position:static elements that are not flex-items get their z-index coerced to auto.
+    if (isPositioned() || createsGroup() || hasClipPath() || hasTransformRelatedProperty() || hasHiddenBackface() || hasReflection() || style()->specifiesColumns() || !style()->hasAutoZIndex() || style()->shouldCompositeForCurrentAnimations())

[skobes, 2015/01/07 18:49:24]

Could you wrap this line at some reasonable length?

[Rick Byers, 2015/01/08 21:08:11]

Done.

+        return NormalLayer;
+    if (style()->hasScrollBlocksOn()) {
+        if (isDocumentElement()) {

[Ian Vollick, 2015/01/06 04:13:51]

Once skobes' root layer scroll refactor is done, this could be accelerated,
right? See https://code.google.com/p/chromium/issues/detail?id=417782.

[skobes, 2015/01/07 18:49:24]

If I'm reading it right, this check is just making sure we don't create separate
RenderLayers for the document and the html element due to the special
propagation of scroll-blocks-on between the two?

[Rick Byers, 2015/01/08 21:08:11]

Right.  I've added a comment to clarify this.

+            ASSERT(style()->scrollBlocksOn() == view()->style()->scrollBlocksOn());
+            return NoLayer;
+        }
+        return NormalLayer;
+    }
+    if (hasOverflowClip())
+        return OverflowClipLayer;
+
+    return NoLayer;
+}
+
 void RenderBox::willBeRemovedFromTree()
 {
     if (m_rareData && m_rareData->m_spannerPlaceholder) {