Bug 80331 - [chromium] Refactor CCLayerTreeHostCommon: untangle drawableContentRect, part 1
Summary: [chromium] Refactor CCLayerTreeHostCommon: untangle drawableContentRect, part 1
Status: RESOLVED DUPLICATE of bug 80622
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Shawn Singh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-05 14:52 PST by Shawn Singh
Modified: 2012-07-16 09:09 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Singh 2012-03-05 14:52:40 PST
The computation and usage of drawableContentRect is one of the most confusing aspects of calculateDrawTransformsAndVisibility:

(1) before recursion, drawableContentRect is initalized to the clipRect (or, if no masksToBounds, the layer's boundaries)
(2) after recursion, drawableContentRect is expanded to include layers, and is then re-clipped if masksToBounds is true.
(3) after all that, the clipRect is re-initialized to the drawableContentRect ... ?!
(4) drawableContentRect should not be a layer property; it is not actually used outside calculateDrawTransformsAndVisibility; it is only used to initialize the target renderSurface's contentRect.

Cleaning this up safely will take multiple patches, this first patch will try to remove some redundancy in the appropriate if statements, before trying to clean up the clipRect/drawableContentRect knot described above.
Comment 1 Dana Jansens 2012-03-26 11:00:11 PDT
This may or may not be the place to fix the clipRect + replica situation. But the clipRect for both the surface is wrong when the surface has a replica (it includes the replica and possibly more), and we don't have a clipRect for just the replica.
Comment 2 Shawn Singh 2012-07-16 09:09:13 PDT

*** This bug has been marked as a duplicate of bug 80622 ***