Update fixed-pos bounds expansion for overlap
The max overlap for fixed feature (crrev.com/766618) had an assumption that the overlap testing rect, as computed by BoundingBoxForCompositingOverlapTest, is in viewport space and includes the area that a fixed-pos layer can occupy given any valid scroll offset. This expansion was limited to just the fixed-pos layer and did not include out-of-flow composited children of the fixed-pos layer. This decision to use viewport space for the expanded rect caused an unrecognized embedding of the scroll offset into the rect position at compositing inputs time when the expanded bounding rect was computed. The dependency on scroll offset could cause incorrect overlap test results when the scroll offset changed and overlap testing re-ran without a compositing inputs update. This was addressed by moving the fixed-pos layer's expanded bounds to absolute space in crrev.com/807955. However, this later revision also caused the children of a fixed-pos element to change from storing their unexpanded overlap test bounding rects in viewport space to storing them in absolute space without expanding their bounds or otherwise compensating for no compositing inputs update on scroll offset. This effectively introduced a dependency on the scroll offset at bounds computation time for children of fixed-pos, leading to crbug.com/1137974 due to incorrect overlap testing results. This was addressed in m87 by reverting revision crrev.com/807955. This change addresses the issue in a different way. The new approach is as follows: 1. Fixed-pos (and their children) compute non-expanded bounds instead of expanded bounds in BoundingBoxForCompositingOverlapTest, now renamed to LocalBoundingBoxForCompositingOverlapTest. These bounds, for fixed-pos layers, are kept in viewport coords when stored on AncestorDependentCompositingInputs, keeping them scrolloffset agnostics as cached. Additionally, by avoiding expanding the bounds, the return values from (un)ClippedAbsoluteBoundingBox are no longer expanded. These return values are used by layer squashing sparsity calculations, meaning this change reverts that calculation to its previous behavior before the MaxOverlapBoundsForFixed feature was introduced. 2. Conversion to absolute coords and expansion happens at overlap testing time, instead of compositing inputs update time, avoiding the problem that was attempted to be addressed via crrev.com/807955. Additionally, children of fixed-pos elements are also converted from viewport to absolute space during overlap testing, avoiding the issue found in crbug.com/1137974. 3. Only the top-most fixed-pos element expands its bounds. Without this limitation, children of a fixed-pos element would also expand their bounds and could detect overlap with siblings that they couldn't actually overlap with. E.g. two absolutely positioned siblings with a common fixed-pos ancestor do not need to expand their bounds to determine if they can overlap. 4. Because of the change in number 3, it becomes important that the fixed-pos layer's bound for overlap includes all that area covered by the fixed-pos layer and any of its children that may have their own composition layer. Without this consideration, it's possible for a child to extend beyond the fixed-pos expanded bounds and not cause something to composite due to overlap even though it intersects when scroll offsets change. This would be fixed on a lifecycle update that re-ran compositing with the new scroll offsets, but is still incorrect behavior. To address this issue, the overlap testing bounds for the top-most fixed-pos layer is expanded to include its composited stacking children. All of these cases also have tests added to validate them. Bug: 1124753 Change-Id: I42b22892fb0040bde8cbabb7c85fe30f71f4ee57 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2522407Reviewed-by:Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by:
Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Sam Fortiner <samfort@microsoft.com> Cr-Commit-Position: refs/heads/master@{#827547}
Showing
This diff is collapsed.
This diff is collapsed.
Please register or sign in to comment