Is the enclosingIntRect() necessary?
If it is, we'll need to handle it in GeometryMapper. This is similar to the other bugs blocking bug 646176 that GeometryMapper lacks information about such extra geometry effects than the paint property tree.
IIRC that's an old legacy thing (used to have comment on it I think...) Had something to do with how passing through enclosingIntRect yields a different result than not for empty rectangles (empty vs. not empty).
Other than empty-rect/etc corner-cases, the only reason I can think of for rounding out at this stage is to avoid unwanted inward-snapping due to FloatRect -> LayoutRect conversion.
So if you're looking at dropping enclosingIntRect(), I suggest replacing with enclosingLayoutRect().
IIRC, enclosingLayoutRect is what gives FloatRect(x, y, 0, 0) -> LayoutRect(x, y, LayoutUnit::epsilon(), LayoutUnit::epsilon()) (i.e rawValue(width/height) == 1)
Recent discussions about pixel snapping let me doubt the correctness of the CL.
When mapping a rect from an SVG object to a container about SVGRoot, we need to apply apply subpixel offset [1] when crossing the SVGRoot boundary. As we don't know the subpixel accumulation of the SVGRoot, the safe way might be to use enclosingIntRect() here (just like what we do at https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutBox.cpp?rcl=0&l=2331).
I would like to restore the enclosingIntRect() and also use it in GeometryMapper when mapping a rect across an SVGRoot object so that we can produce the same results for the old path and slimmingPaintInvalidation. Then we can try to improve GeometryMapper to produce accurate pixel snapping based on the known subpixel accumulation of SVGRoot.
[1] The subpixel offset is to align SVGRoot's client space (or border-box space) to whole pixels. It's not an offset to align an SVG rect mapped to SVGRoot's space to whole pixels because we should only align SVGRoot parts, not any child SVG objects.
Comment 1 by f...@opera.com
, Sep 29 2016