Changeset 122120 in webkit


Ignore:
Timestamp:
Jul 9, 2012 11:37:28 AM (12 years ago)
Author:
danakj@chromium.org
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:
Location:
trunk/Source
Files:
4 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebCore/ChangeLog

    r122119 r122120  
     12012-07-09  Dana Jansens  <danakj@chromium.org>
     2
     3        [chromium] Create render surfaces on main thread only for the current frame
     4        https://bugs.webkit.org/show_bug.cgi?id=89793
     5
     6        Reviewed by Adrienne Walker.
     7
     8        Previously we would create render surfaces for animating layers
     9        in the main thread since these layers might have a surface on impl,
     10        in order to assist culling. This makes it very difficult to estimate
     11        how much texture memory is needed for RenderSurfaces on the main
     12        thread, in order to keep contents+surface memory below our limit.
     13
     14        Here we stop doing this, and create RenderSurfaces on both threads
     15        under the same conditions, so main thread has surfaces only if the
     16        layers in its current frame demand them. While this may reduce
     17        paint culling within an animating subtree, this seems like an edge
     18        case and knowing the amount of surface memory needed for the frame
     19        is important.
     20
     21        Animation tests in CCLayerTreeHostCommonTest used to verify that these
     22        layers got surfaces, so now no longer do. Creation of surfaces under
     23        other conditions is covered by other CCLayerTreeHostCommonTests.
     24
     25        * platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp:
     26        (WebCore::subtreeShouldRenderToSeparateSurface):
     27
    1282012-07-09  Ryosuke Niwa  <rniwa@webkit.org>
    229
  • trunk/Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp

    r120847 r122120  
    189189}
    190190
    191 static inline bool layerOpacityIsOpaque(CCLayerImpl* layer)
    192 {
    193     return layer->opacity() == 1;
    194 }
    195 
    196 static inline bool layerOpacityIsOpaque(LayerChromium* layer)
    197 {
    198     // If the opacity is being animated then the opacity on the main thread is unreliable
    199     // (since the impl thread may be using a different opacity), so it should not be trusted.
    200     // In particular, it should not be treated as opaque.
    201     return layer->opacity() == 1 && !layer->opacityIsAnimating();
    202 }
    203 
    204191static inline bool transformToParentIsKnown(CCLayerImpl*)
    205192{
     
    304291
    305292    // If the layer clips its descendants but it is not axis-aligned with respect to its parent.
    306     // On the main thread, when the transform is being animated, it is treated as unknown and we
    307     // always error on the side of making a render surface, to let us consider descendents as
    308     // not animating relative to their target to aid culling.
    309     if (layer->masksToBounds() && (!axisAlignedWithRespectToParent || !transformToParentIsKnown(layer)) && descendantDrawsContent)
     293    if (layer->masksToBounds() && !axisAlignedWithRespectToParent && descendantDrawsContent)
    310294        return true;
    311295
    312296    // If the layer has opacity != 1 and does not have a preserves-3d transform style.
    313     // On the main thread, when opacity is being animated, it is treated as neither 1
    314     // nor 0.
    315     if (!layerOpacityIsOpaque(layer) && !layer->preserves3D() && descendantDrawsContent)
     297    if (layer->opacity() != 1 && !layer->preserves3D() && descendantDrawsContent)
    316298        return true;
    317299
  • trunk/Source/WebKit/chromium/ChangeLog

    r122115 r122120  
     12012-07-09  Dana Jansens  <danakj@chromium.org>
     2
     3        [chromium] Create render surfaces on main thread only for the current frame
     4        https://bugs.webkit.org/show_bug.cgi?id=89793
     5
     6        Reviewed by Adrienne Walker.
     7
     8        * tests/CCLayerTreeHostCommonTest.cpp:
     9
    1102012-07-02  Ryosuke Niwa  <rniwa@webkit.org>
    211
  • trunk/Source/WebKit/chromium/tests/CCLayerTreeHostCommonTest.cpp

    r121628 r122120  
    21842184    childOfRS2->addChild(grandChildOfRS2);
    21852185
    2186     // In combination with descendantDrawsContent, opacity != 1 forces the layer to have a new renderSurface.
     2186    // Make our render surfaces.
     2187    renderSurface1->setForceRenderSurface(true);
     2188    renderSurface2->setForceRenderSurface(true);
     2189
     2190    // Put an animated opacity on the render surface.
    21872191    addOpacityTransitionToController(*renderSurface1->layerAnimationController(), 10, 1, 0, false);
    21882192
     
    21952199    sublayerTransform.scale3d(10.0, 1.0, 1.0);
    21962200
    2197     // In combination with descendantDrawsContent and masksToBounds, an animated transform forces the layer to have a new renderSurface.
     2201    // Put a transform animation on the render surface.
    21982202    addAnimatedTransformToController(*renderSurface2->layerAnimationController(), 10, 30, 0);
    2199     renderSurface2->setMasksToBounds(true);
    22002203
    22012204    // Also put transform animations on grandChildOfRoot, and grandChildOfRS2
     
    27942797    backfaceMatrix.translate(-50, -50);
    27952798
    2796     // Having a descendant that draws, masksToBounds, and animating transforms, will make the animatingSurface own a render surface.
     2799    // Make our render surface.
     2800    animatingSurface->setForceRenderSurface(true);
     2801
     2802    // Animate the transform on the render surface.
    27972803    addAnimatedTransformToController(*animatingSurface->layerAnimationController(), 10, 30, 0);
    2798     animatingSurface->setMasksToBounds(true);
    27992804    // This is just an animating layer, not a surface.
    28002805    addAnimatedTransformToController(*animatingChild->layerAnimationController(), 10, 30, 0);
Note: See TracChangeset for help on using the changeset viewer.