Suppress layer creation for descendants of GPU-rasterized layers

Source/core/rendering/RenderObject.cpp

Index: Source/core/rendering/RenderObject.cpp
diff --git a/Source/core/rendering/RenderObject.cpp b/Source/core/rendering/RenderObject.cpp
index 2ef143e69c780f09279da570d31648723a065ea4..fe241b5114a125e289a68530a5ff813e5c6e1a20 100644
--- a/Source/core/rendering/RenderObject.cpp
+++ b/Source/core/rendering/RenderObject.cpp
@@ -1848,6 +1848,8 @@ void RenderObject::handleDynamicFloatPositionChange()
 
 StyleDifference RenderObject::adjustStyleDifference(StyleDifference diff, unsigned contextSensitiveProperties) const
 {
+    // FIXME: The calls to hasDirectReasonsForCompositing are using state that may not be up to date.
+    DisableCompositingQueryAsserts disabler;

[abarth-chromium, 2014/04/17 17:29:51]

This should be asking whether we have any style-determined reasons for
compositing.

Maybe this will cause a bug with your CL because we'll think we have compositing
reasons but then we won't actually create a graphics layer because we'll
suppress the creation of the layer?

[ajuma, 2014/04/17 19:24:44]

Yes, switching to styleDeterminedReasons() does cause a bug, where we fail to
repaint because we think we have a composited layer when we don't have one (test
case: http://jsfiddle.net/c59gC/). I'll switch this to styleDeterminedReasons()
(and fix the resulting bug) in a follow-up.

     // If transform changed, and the layer does not paint into its own separate backing, then we need to do a layout.
     // FIXME: The comment above is what the code does, but it is technically not following spec. This means we will
     // not to layout for 3d transforms, but we should be invoking a simplified relayout. Is it possible we are avoiding