Closed
Bug 1375785
Opened 7 years ago
Closed 7 years ago
Right-size ContainerLayers during LayerTreeInvalidation
Categories
(Core :: Graphics: Layers, enhancement)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox56 | --- | fixed |
People
(Reporter: dvander, Assigned: dvander)
References
Details
Attachments
(1 file, 1 obsolete file)
8.61 KB,
patch
|
mattwoodrow
:
review+
|
Details | Diff | Splinter Review |
Layout sometimes computes the visible region of container layers inaccurately. In the past this hasn't mattered because the region is effectively ignored, and recomputed by the compositor. The function that does this is PostProcessLayers - it performs occlusion culling, and also happens to reset each container's visible region to be the sum of the visible regions of its children. This ends up masking bugs where the visible region computed by layout is too big or too small. Also, PostProcessLayers runs *before* LayerTreeInvalidation, so invalidation is using the result of occlusion culling. (It should really be called "PreProcessLayers".) Advanced Layers has the opposite behavior: it invalidates first, then performs occlusion culling on the invalid region. Since the second step happens in a single pass, there is no opportunity to compute the true visible region of containers. Thus when layout has computed too small a region, we render incorrectly (like bug 1359709). When the region is too big, we're allocating excess texture memory and drawing extra pixels. I'm not sure how big a deal it really is, it's not a common occurrence. But it's worth fixing. Two possibilities for fixing it: (1) Delay intermediate surface creation until we finish processing a container's children. Then we can sum up the bounds of children. However this would occur after invalidation, so we'd have to be sure that any size changes we compute were also computed by LTI. (2) Do the calculation in LTI, since it already looks at layer bounds.
Assignee | ||
Comment 1•7 years ago
|
||
Turns out option (1) is difficult because AL bakes the render target offset into its draw calls, and we'd have to extend the surface size to include it. Option (2) doesn't make sense because LTI only visits layers from the previous draw, not the current one. Maybe we just have to calculate it the hard way. This patch recursively adds up the visible bounds of leaf layers if we (1) don't yet have an intermediate surface or (2) LTI computes that a child of the container has changed.
Attachment #8881018 -
Flags: review?(matt.woodrow)
Assignee | ||
Comment 2•7 years ago
|
||
This now takes clips into account. It's not pretty but it looks pretty similar to PostProcessLayers.
Attachment #8881018 -
Attachment is obsolete: true
Attachment #8881018 -
Flags: review?(matt.woodrow)
Attachment #8881856 -
Flags: review?(matt.woodrow)
Updated•7 years ago
|
Attachment #8881856 -
Flags: review?(matt.woodrow) → review+
Pushed by danderson@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4ef2bbae969a Compute minimal intermediate surface sizes in Advanced Layers. (bug 1375785, r=mattwoodrow)
Comment 4•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4ef2bbae969a
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in
before you can comment on or make changes to this bug.
Description
•