Bug 87554 - Clean up code that has to handle compositing changes on a layer
Summary: Clean up code that has to handle compositing changes on a layer
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-25 17:40 PDT by Simon Fraser (smfr)
Modified: 2012-05-25 17:42 PDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2012-05-25 17:40:30 PDT 
We have code in various places that deals with fallout from making a RenderLayer composited, or not. RenderLayerCompositor::updateBacking() has this:

            if (layer->parent())
                layer->computeRepaintRects();
and

    if (layerChanged)
        layer->clearClipRectsIncludingDescendants(PaintingClipRects);

It's not clear if there are all doing the right thing. Why doesn't computeRepaintRects() have to be called for all non-composited descendant layers?

We should have one bottleneck for "my compositing state changed, do stuff to descendants".
Comment 1 Simon Fraser (smfr) 2012-05-25 17:42:06 PDT 
Also, some of these things should happen when a backing's 'm_requiresOwnBackingStore' changes.