Handle geometry effects of filters in GeometryMapper

third_party/WebKit/LayoutTests/paint/invalidation/filters/effect-reference-repaint-composite-1-expected.txt

Index: third_party/WebKit/LayoutTests/paint/invalidation/filters/effect-reference-repaint-composite-1-expected.txt
diff --git a/third_party/WebKit/LayoutTests/paint/invalidation/filters/effect-reference-repaint-composite-1-expected.txt b/third_party/WebKit/LayoutTests/paint/invalidation/filters/effect-reference-repaint-composite-1-expected.txt
index 064c8793b0f71275e224e2aab5b8c1789605b093..5f0b3765c128ad853b367b5f8b181b8858ec9de0 100644
--- a/third_party/WebKit/LayoutTests/paint/invalidation/filters/effect-reference-repaint-composite-1-expected.txt
+++ b/third_party/WebKit/LayoutTests/paint/invalidation/filters/effect-reference-repaint-composite-1-expected.txt
@@ -8,7 +8,7 @@
       "paintInvalidations": [
         {
           "object": "LayoutBlockFlow DIV class='box'",
-          "rect": [128, 120, 200, 200],
+          "rect": [28, 20, 300, 300],

[Xianzhu, 2017/01/26 23:17:45]

This is because now we use cc side effect mapRect, which sometimes is different
from the blink side one. There seems no regressions.

[chrishtr, 2017/02/01 02:59:12]

Do you know what is different about the two implementations of mapRect? Maybe
there is a bug in there.

[Xianzhu, 2017/02/03 01:38:16]

<div class="before box"></div>
<svg width="0" height="0">
  <filter id="composite" x="-0.5" y="-0.5" width="2" height="2">
    <feFlood x="100" y="100" width="200" height="200" flood-color="red"/>
    <feComposite operator="in" in="SourceGraphic"/>
  </filter>
</svg>

The difference seems for feComposite:

blink (blink::ReferenceFilterOperation):
  feFlood: 100,100 200x200
  feComposite: 100,100 200x200
  result is 100,100 200x200

skia (SkImageFilter):
  feFlood: 100,100 200x200
  feComposite: 0,0 200x200
  result is union of the above: 0, 0, 300, 300

Skia seems to use a simple method that
- just uses input as feComposite bounds;
- and unions the bounds which definitely covers any feComposite combinations
but the rect may be larger than optimal.

The blink result seems also not optimal.

If I understand it correctly, the optimal result should be (100,100 100x100)
which is the intersection of the two inputs of feComposite.

Perhaps the suboptimility is acceptable?

[Stephen White, 2017/02/07 18:26:41]

This optimization was landed by the Swiffy folks in Blink a long while back for
an actual use case, back when they used SVG rather than Canvas. It's something 
I've been meaning to move to Skia for some time, but haven't had a chance. It 
would be unfortunate to lose it, but I don't think it would be crippling. 
Unfortunately they didn't land a perf test at the time either.

[Xianzhu, 2017/02/07 21:23:51]

Thanks Stephen for the explanation.

I would like to avoid the regression in production by keeping PaintInvalidator
as-is and limiting the change in GeometryMapper only. There seems no big
advantage for PaintInvalidator to use GeometryMapper for filters, while spv2 may
benefit from GeometryMapper with filter support.

Chris, does this sound good to you?

           "reason": "style change"
         }
       ]