Defer the real work in updateCompositingLayers until it's really needed.

Source/core/rendering/CompositedLayerMapping.cpp

Index: Source/core/rendering/CompositedLayerMapping.cpp
diff --git a/Source/core/rendering/CompositedLayerMapping.cpp b/Source/core/rendering/CompositedLayerMapping.cpp
index 15d68d49e4cc2871888995dc7e3fcf9255985646..43c948cea7bf219da3fb33bda5c78f363fddfb88 100644
--- a/Source/core/rendering/CompositedLayerMapping.cpp
+++ b/Source/core/rendering/CompositedLayerMapping.cpp
@@ -750,6 +750,8 @@ void CompositedLayerMapping::updateGraphicsLayerGeometry()
         }
     }
 
+    m_owningLayer->positionOverflowControls();

[Ian Vollick, 2013/10/17 01:30:25]

What's the reason for this change?

[shawnsingh, 2013/10/17 01:44:04]

Because we defer computing compositing, we may not decide to composite a layer
before updateLayerPositions() is called.  updateLayerPositions is where
composited scrollbars were being positioned, so in that scenario, positioning
composited scrollbars was getting skipped.  The CompositedLayerMapping here,
which manages those scrollbars, should be the one responsible for re-positioning
composited scrollbars.   Eventually we should be able to remove the code that
positions composited scrollbars from updateLayerPositions, but for now to be
safe, I left it there.

+
     // If this layer was created just for clipping or to apply perspective, it doesn't need its own backing store.
     setRequiresOwnBackingStore(compositor()->requiresOwnBackingStore(m_owningLayer, compAncestor));