For clip-path-clipped-evenodd-twice.svg, we have a clip path that applies to another clip path. The display item client for the first clip path is the clipped target which has a visualRect, but the display item client for the second (nested) clip path is a clip path which has an empty visual rect. We cannot rely on the visual rect being directly available through the display item client in this case. There are a few solutions but I think we should just explicitly track the visual rect in the clip path display item which we have at the display item creation callsites.

The second class of bugs includes zoom-foreignObject.svg and is more complex. One bug is that SVGForeignObject supports overflow clip (sort of) but was missing a paint over-invalidation hack that blocks use. I have a work in progress that fixes this (https://codereview.chromium.org/1835843002). There is at least one more bug that causes the foreignObject tests to fail though. Don't touch that dial; we will have more breaking news after this short break...

css3/filters/effect-reference-hidpi.html looks like it is another SVG specific failure re: SVG filters. See expectations at:

https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/84522/layout-test-results/results.html

pdr@ did not think this bug should block launch when we last discussed.

I don't think we should ship things that are known broken. We're also losing test coverage which might mask further breakage. Is there a plan to fix these soonish?

Just to update with my recollection -- when I discussed these with pdr@ in person when we filed the bug it was my understanding that he felt there were other open SVG bugs that were more impactful and higher priority to fix than these. He should comment when he can.

@wkorman, how hard would it be to knock out the bugs in comment 2 with this landed? With our experience in this area and the description in that comment, this seems pretty practical.

@senorblanco, I definitely understand not wanting to let regressions through. When walter and I discussed this last, we thought the across-the-board perf win would be more important to than two obscure svg bugs. The issues in comment #2 are existing bugs but they are masked in various ways. That was my reasoning at the time, though it may have been a bad decision.

I'll take a look at this Thu next week.

Four tests involved in this bug:

css3/filters/effect-reference-hidpi.html
svg/custom/absolute-sized-content-with-resources.xhtml
svg/overflow/overflow-on-foreignObject.svg
svg/zoom/page/zoom-foreignObject.svg

Notes on zoom-foreignObject.svg --

Commenting out the second text block (svg foreign object) to focus on the html foreign object, the visual rect for the first line of text remains same from (A) initial frame to (B) the zoomed frame:

(A) 17:25:05.647 4920   {index: 4, client: "0x330c39668010 InlineTextBox 'This is a text'", type: "DrawingPaintPhaseForeground", rect: [0.000000,0.000000 75.000000x19.000000], cacheIsValid: true, visualRect: [0,0 230x78]},
(B) 17:25:05.648 4920   {index: 5, client: "0x330c39668010 InlineTextBox 'This is a text'", type: "DrawingPaintPhaseForeground", rect: [0.000000,0.000000 75.000000x19.000000], cacheIsValid: true, visualRect: [0,0 230x78]},

whereas most all other display items see their cull rect/visual rect grow for example:

(A) 17:25:05.647 4920   {index: 5, client: "0x330c39668088 InlineTextBox 'and a link.'", type: "DrawingPaintPhaseForeground", rect: [0.000000,20.000000 62.000000x19.000000], cacheIsValid: true, visualRect: [5,60 192x75]},
(B) 17:25:05.648 4920   {index: 6, client: "0x330c39668088 InlineTextBox 'and a link.'", type: "DrawingPaintPhaseForeground", rect: [0.000000,20.000000 62.000000x19.000000], cacheIsValid: true, visualRect: [7,87 276x107]},

It's particularly surprising since the '[HTML]' text in the test is:

  <xhtml:div>[HTML]</xhtml:div>

just like the one with the seemingly illegitimate visual rect two lines of code prior:

  <xhtml:div>This is a text</xhtml:div>

and yet:

(A) 17:35:15.446 1538   {index: 7, client: "0x12e848464178 InlineTextBox '[HTML]'", type: "DrawingPaintPhaseForeground", rect: [0.000000,40.000000 53.000000x19.000000], cacheIsValid: true, visualRect: [10,120 165x73]},
(B) 17:35:15.448 1538   {index: 8, client: "0x12e848464178 InlineTextBox '[HTML]'", type: "DrawingPaintPhaseForeground", rect: [0.000000,40.000000 53.000000x19.000000], cacheIsValid: true, visualRect: [15,174 237x103]},

I also wonder whether the cull rect is supposed to be growing in tandem with the visual rect. To investigate further.

Update -- patches are out for review for  crbug.com/640265  and  crbug.com/640273 . One of the four issues was closed with rebaseline. This leaves only  crbug.com/640264  which pdr@ is working on.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e465f9c7e83038547530b26bd26c432726a11020

commit e465f9c7e83038547530b26bd26c432726a11020
Author: pdr <pdr@chromium.org>
Date: Tue Aug 30 18:27:54 2016

Add new filter repaint test for turbulence, rebaseline existing test

This patch adds a new (currently failing) filter repaint test to show
how we improperly repaint turbulence filters. In addition, the existing
test for 640264 has been unskipped and rebaselined with a failing
result. These two changes should help catch progressions in the future.

BUG= 598051 , 640264 

Review-Url: https://codereview.chromium.org/2294633002
Cr-Commit-Position: refs/heads/master@{#415363}

[modify] https://crrev.com/e465f9c7e83038547530b26bd26c432726a11020/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/e465f9c7e83038547530b26bd26c432726a11020/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-turbulence-expected.png
[add] https://crrev.com/e465f9c7e83038547530b26bd26c432726a11020/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-turbulence-expected.txt
[add] https://crrev.com/e465f9c7e83038547530b26bd26c432726a11020/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-turbulence.html
[modify] https://crrev.com/e465f9c7e83038547530b26bd26c432726a11020/third_party/WebKit/LayoutTests/platform/win/css3/filters/effect-reference-hidpi-expected.png

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/079ac671bc155405d5d544ce2fe27b017e668e8e

commit 079ac671bc155405d5d544ce2fe27b017e668e8e
Author: yhirano <yhirano@chromium.org>
Date: Wed Aug 31 04:31:46 2016

Suppress css3/filters/filter-repaint-turbulence.html test failure

BUG= 598051 
TBR=senorblanco@chromium.org,wkorman@chromium.org,pdr@chromium.org

Review-Url: https://codereview.chromium.org/2289123004
Cr-Commit-Position: refs/heads/master@{#415559}

[modify] https://crrev.com/079ac671bc155405d5d544ce2fe27b017e668e8e/third_party/WebKit/LayoutTests/TestExpectations

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/520d650321c36955eeb2f2e9620bbf16100eae34

commit 520d650321c36955eeb2f2e9620bbf16100eae34
Author: pdr <pdr@chromium.org>
Date: Wed Aug 31 21:26:47 2016

Suppress filter-repaint-turbulence.html in debug and release

This test is still failing after the suppression in [1]:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=css3%2Ffilters%2Ffilter-repaint-turbulence.html

This patch marks the test as pass/fail for both debug and release.

[1] https://crrev.com/079ac671bc155405d5d544ce2fe27b017e668e8e

BUG= 598051 
NOTRY=true

Review-Url: https://codereview.chromium.org/2301523004
Cr-Commit-Position: refs/heads/master@{#415759}

[modify] https://crrev.com/520d650321c36955eeb2f2e9620bbf16100eae34/third_party/WebKit/LayoutTests/TestExpectations

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/873f27d84aaf55a3ee7ccfb0583639464efaf7bf

commit 873f27d84aaf55a3ee7ccfb0583639464efaf7bf
Author: pdr <pdr@chromium.org>
Date: Tue Sep 13 20:11:45 2016

Add new filter repaint tests for underinvalidation

This patch adds two new (currently failing) filter repaint tests to show
how we improperly repaint turbulence and image filters. These two tests
should help catch progressions in the future.

BUG= 598051 , 640264 

Review-Url: https://codereview.chromium.org/2305023003
Cr-Commit-Position: refs/heads/master@{#418347}

[modify] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-feimage-expected.png
[add] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-feimage-expected.txt
[add] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-feimage.html
[add] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-turbulence-expected.png
[add] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-turbulence-expected.txt
[add] https://crrev.com/873f27d84aaf55a3ee7ccfb0583639464efaf7bf/third_party/WebKit/LayoutTests/css3/filters/filter-repaint-turbulence.html

All blocking bugs fixed, no remaining entries in TestExpectations.