New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 597813 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

LayoutSVGRoot::mapToVisibleRectInAncestorSpace() should not apply viewport clip on its own rect

Project Member Reported by wangxianzhu@chromium.org, Mar 24 2016

Issue description

When a SVGRoot itself is being invalidated, it should not apply viewport clip on its own rect.

In mapToVisibleRectInAncestorSpace(), we should apply container clip and scroll offset in children's mapToVisibleRectInAncestorSpace() instead of the container's. See LayoutBox::mapToVisibleRectInAncestorSpace().
 
Previously this issue was hidden because LayoutSVGRoot::clippedOverflowRectForPaintInvalidation() explicitly calls LayoutReplaced::mapToVisibleRectInAncestorSpace() instead of its own mapToVisibleRectInAncestorSpace().
Is it hard to fix?
Cc: -trchen@chromium.org wangxianzhu@chromium.org
Owner: trchen@chromium.org
Status: Assigned (was: Available)
Not hard for fixing issue itself.

Discussed with trchen@ and he had an idea to separate mapToVisibleRectInAncestorSpace() (and other mapping functions) into two parts:
1. map from object local space (e.g. border box space) to container's contents space (e.g. scrolling box space);
2. map from contents space to local space.

Currently 2 for the container is called in child's mapToVisibleRectInAncestorSpace(), but with some exceptions which are wrong (e.g. LayoutSVGRoot). This requires the each child having its own way to do 1 to also know how to do 2 for the container. It would be clearer and less error-prone if we separate 2 into a method of the container objects. Trchen@ might work on this after my paint invalidation CLs are landed.

However, will GeometryMapper cover such things?


GeometryMapper does not cover this. GeometryMapper requires inputs (and outputs) that are in a well-defined property tree state, which means the space that SPv2 paintOffset is relative to: the space of the containing transform node.
Cc: -wangxianzhu@chromium.org trchen@chromium.org
Owner: wangxianzhu@chromium.org
My current work will cover this bug.
Status: Fixed (was: Assigned)

Sign in to add a comment