[Webkit-unassigned] [Bug 70634] Mark GraphicsLayers as opaque when possible

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 8 08:01:17 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=70634





--- Comment #39 from Dana Jansens <danakj at chromium.org>  2011-11-08 08:01:16 PST ---
This version moves the walk of RenderObjects to the RenderObject::layout() code paths.

I'm not sure if this will be an overall win when compared to the previous version, but will leave it to you to judge. This buys us more lines of code (37 more), and spreads the opaque computation out to 3 classes:
- RenderLayerCompositor walks RenderLayers, collects their opaque regions, and determines if they cover the entire backing.
- RenderLayer holds a set of opaque regions given to it by RenderObjects.
- RenderObject computes an opaque region for itself after layout() and gives it to its enclosingLayer().

When a RenderObject saves its opaque rectangle, it needs to save an offset relative to its enclosing RenderLayer.  The old code did this by keeping an aggregate offset and thus required no extra computation to determine the offset. We don't have the same information here in this version, so after a RenderObject completes its layout(), we have to walk up to the enclosing RenderLayer to determine its offset (also to determine its enclosing RenderLayer).

I see code that walks up to container() used a fair bit in the layout code, so the above walk up to enclosingLayer() may not be a big deal in this part of the code (compared to RenderLayerCompositor::calculateCompositedBounds(), but I wanted to point it out.

It would be possible to pass data along to subsequent layout() calls when recursing down the tree, saving some walking (only walk to nearest container() not to enclosingLayer()), but I did not do that since the layout() function is sprinkled around something like 15 classes in the RenderObject hierarchy and it seemed a poor idea to make that sort of change.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list