Title: [122120] trunk/Source
Revision
122120
Author
[email protected]
Date
2012-07-09 11:37:28 -0700 (Mon, 09 Jul 2012)

Log Message

[chromium] Create render surfaces on main thread only for the current frame
https://bugs.webkit.org/show_bug.cgi?id=89793

Reviewed by Adrienne Walker.

Source/WebCore:

Previously we would create render surfaces for animating layers
in the main thread since these layers might have a surface on impl,
in order to assist culling. This makes it very difficult to estimate
how much texture memory is needed for RenderSurfaces on the main
thread, in order to keep contents+surface memory below our limit.

Here we stop doing this, and create RenderSurfaces on both threads
under the same conditions, so main thread has surfaces only if the
layers in its current frame demand them. While this may reduce
paint culling within an animating subtree, this seems like an edge
case and knowing the amount of surface memory needed for the frame
is important.

Animation tests in CCLayerTreeHostCommonTest used to verify that these
layers got surfaces, so now no longer do. Creation of surfaces under
other conditions is covered by other CCLayerTreeHostCommonTests.

* platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp:
(WebCore::subtreeShouldRenderToSeparateSurface):

Source/WebKit/chromium:

* tests/CCLayerTreeHostCommonTest.cpp:

Modified Paths

Diff

Modified: trunk/Source/WebCore/ChangeLog (122119 => 122120)


--- trunk/Source/WebCore/ChangeLog	2012-07-09 18:32:01 UTC (rev 122119)
+++ trunk/Source/WebCore/ChangeLog	2012-07-09 18:37:28 UTC (rev 122120)
@@ -1,3 +1,30 @@
+2012-07-09  Dana Jansens  <[email protected]>
+
+        [chromium] Create render surfaces on main thread only for the current frame
+        https://bugs.webkit.org/show_bug.cgi?id=89793
+
+        Reviewed by Adrienne Walker.
+
+        Previously we would create render surfaces for animating layers
+        in the main thread since these layers might have a surface on impl,
+        in order to assist culling. This makes it very difficult to estimate
+        how much texture memory is needed for RenderSurfaces on the main
+        thread, in order to keep contents+surface memory below our limit.
+
+        Here we stop doing this, and create RenderSurfaces on both threads
+        under the same conditions, so main thread has surfaces only if the
+        layers in its current frame demand them. While this may reduce
+        paint culling within an animating subtree, this seems like an edge
+        case and knowing the amount of surface memory needed for the frame
+        is important.
+
+        Animation tests in CCLayerTreeHostCommonTest used to verify that these
+        layers got surfaces, so now no longer do. Creation of surfaces under
+        other conditions is covered by other CCLayerTreeHostCommonTests.
+
+        * platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp:
+        (WebCore::subtreeShouldRenderToSeparateSurface):
+
 2012-07-09  Ryosuke Niwa  <[email protected]>
 
         Mac build fix after r122116.

Modified: trunk/Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp (122119 => 122120)


--- trunk/Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp	2012-07-09 18:32:01 UTC (rev 122119)
+++ trunk/Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp	2012-07-09 18:37:28 UTC (rev 122120)
@@ -188,19 +188,6 @@
            && m.m44();
 }
 
-static inline bool layerOpacityIsOpaque(CCLayerImpl* layer)
-{
-    return layer->opacity() == 1;
-}
-
-static inline bool layerOpacityIsOpaque(LayerChromium* layer)
-{
-    // If the opacity is being animated then the opacity on the main thread is unreliable
-    // (since the impl thread may be using a different opacity), so it should not be trusted.
-    // In particular, it should not be treated as opaque.
-    return layer->opacity() == 1 && !layer->opacityIsAnimating();
-}
-
 static inline bool transformToParentIsKnown(CCLayerImpl*)
 {
     return true;
@@ -303,16 +290,11 @@
         return true;
 
     // If the layer clips its descendants but it is not axis-aligned with respect to its parent.
-    // On the main thread, when the transform is being animated, it is treated as unknown and we
-    // always error on the side of making a render surface, to let us consider descendents as
-    // not animating relative to their target to aid culling.
-    if (layer->masksToBounds() && (!axisAlignedWithRespectToParent || !transformToParentIsKnown(layer)) && descendantDrawsContent)
+    if (layer->masksToBounds() && !axisAlignedWithRespectToParent && descendantDrawsContent)
         return true;
 
     // If the layer has opacity != 1 and does not have a preserves-3d transform style.
-    // On the main thread, when opacity is being animated, it is treated as neither 1
-    // nor 0.
-    if (!layerOpacityIsOpaque(layer) && !layer->preserves3D() && descendantDrawsContent)
+    if (layer->opacity() != 1 && !layer->preserves3D() && descendantDrawsContent)
         return true;
 
     return false;

Modified: trunk/Source/WebKit/chromium/ChangeLog (122119 => 122120)


--- trunk/Source/WebKit/chromium/ChangeLog	2012-07-09 18:32:01 UTC (rev 122119)
+++ trunk/Source/WebKit/chromium/ChangeLog	2012-07-09 18:37:28 UTC (rev 122120)
@@ -1,3 +1,12 @@
+2012-07-09  Dana Jansens  <[email protected]>
+
+        [chromium] Create render surfaces on main thread only for the current frame
+        https://bugs.webkit.org/show_bug.cgi?id=89793
+
+        Reviewed by Adrienne Walker.
+
+        * tests/CCLayerTreeHostCommonTest.cpp:
+
 2012-07-02  Ryosuke Niwa  <[email protected]>
 
         Make HTMLCollection RefCounted

Modified: trunk/Source/WebKit/chromium/tests/CCLayerTreeHostCommonTest.cpp (122119 => 122120)


--- trunk/Source/WebKit/chromium/tests/CCLayerTreeHostCommonTest.cpp	2012-07-09 18:32:01 UTC (rev 122119)
+++ trunk/Source/WebKit/chromium/tests/CCLayerTreeHostCommonTest.cpp	2012-07-09 18:37:28 UTC (rev 122120)
@@ -2183,7 +2183,11 @@
     childOfRS1->addChild(grandChildOfRS1);
     childOfRS2->addChild(grandChildOfRS2);
 
-    // In combination with descendantDrawsContent, opacity != 1 forces the layer to have a new renderSurface.
+    // Make our render surfaces.
+    renderSurface1->setForceRenderSurface(true);
+    renderSurface2->setForceRenderSurface(true);
+
+    // Put an animated opacity on the render surface.
     addOpacityTransitionToController(*renderSurface1->layerAnimationController(), 10, 1, 0, false);
 
     // Also put an animated opacity on a layer without descendants.
@@ -2194,9 +2198,8 @@
     WebTransformationMatrix sublayerTransform;
     sublayerTransform.scale3d(10.0, 1.0, 1.0);
 
-    // In combination with descendantDrawsContent and masksToBounds, an animated transform forces the layer to have a new renderSurface.
+    // Put a transform animation on the render surface.
     addAnimatedTransformToController(*renderSurface2->layerAnimationController(), 10, 30, 0);
-    renderSurface2->setMasksToBounds(true);
 
     // Also put transform animations on grandChildOfRoot, and grandChildOfRS2
     addAnimatedTransformToController(*grandChildOfRoot->layerAnimationController(), 10, 30, 0);
@@ -2793,9 +2796,11 @@
     backfaceMatrix.rotate3d(0, 1, 0, 180);
     backfaceMatrix.translate(-50, -50);
 
-    // Having a descendant that draws, masksToBounds, and animating transforms, will make the animatingSurface own a render surface.
+    // Make our render surface.
+    animatingSurface->setForceRenderSurface(true);
+
+    // Animate the transform on the render surface.
     addAnimatedTransformToController(*animatingSurface->layerAnimationController(), 10, 30, 0);
-    animatingSurface->setMasksToBounds(true);
     // This is just an animating layer, not a surface.
     addAnimatedTransformToController(*animatingChild->layerAnimationController(), 10, 30, 0);
 
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to