Bug 44635 – Scrolling causes image pattern fill to be rendered incorrectly

• Component: SVG
• Status: RESOLVED FIXED

Created attachment 65475 [details]
Testcase for the bug

Scrolling an XHTML page with embedded <svg> would cause pattern fill with the <svg> to be rendered incorrectly.

Steps to reproduce: 

1. Open the attached testcase
2. Open svg-scroll-pattern-corruption/index.xhtml
3. There should be an image on the page
4. Now resize the window to be shorter than the image so vertical scroll bar would appear
5. Reload the page
6. Now the bottom part of the image should be "cropped" by the browser window
7. Scroll down and up repeatedly to see the rendered pattern fill corrupts

[Matthew Delaney]

Please update the steps to reproduce so that there's a clear "expected" result and "actual" result following the simplest and clearest set of numbered steps to reproduce the bug that you can come up with. Currently, steps 6 and 7 aren't clear to me. (So, basically, separate out the actual/expected results from the steps to reproduce and make sure the steps are as few, as simple, and as clear as possible.) Thanks!

Here are some additional information. 

Expected behavior: 

The pattern fill image should scroll normally. 

Actual behavior: 

The pattern fill image is rendered incorrectly after scrolling. 

Additional information: 

Step 5 in "Steps to reproduce" is not necessary to trigger the rendering bug. 
Step 6 in "Steps to reproduce" is to verify the image itself is large than the browser window and is not part of the bug itself. 

Here is the updated steps to reproduce the bug. 

1. Open the attached testcase
2. Open svg-scroll-pattern-corruption/index.xhtml
3. There should be an image on the page
4. Now resize the window to be shorter than the image so vertical scroll bar would appear
5. Scroll down and up repeatedly to see the rendered pattern fill corrupts

[Dirk Schulze]

(In reply to comment #2)
Works for me on Chromium and WebKitGtk, no corruptions.

[Dirk Schulze]

Can you specify corruption? Maybe you're testing with Safari 5 or an older version and this corruption is a repeating of the first visible lines of the image as a tile. But this is fixed for some month now.

Did you check this with trunk?

Created attachment 65481 [details]
Screenshot for pattern fill image corruption

Screenshot to illustrate the bug. 
Captured on WebKit Version 5.0.1 (6533.17.8, r65825) after scrolling up and down a few times.

[Nikolas Zimmermann]

I'm aware of this bug. It also affects standalone SVG files.
Open svg/W3C-SVG-1.1/pservers-pattern-01-b.svg zoom in a few times, so that scrollbars get visible.
Scroll down to the bottom, slowly scroll up.

I have no idea what might cause this :(

[Simon Fraser (smfr)]

Repaint issue?

[Nikolas Zimmermann]

(In reply to comment #7)
> Repaint issue?

Quartz debug shows nothing is repainted, while scrolling. Do you have any clue what might cause this?

[Simon Fraser (smfr)]

Related to bug 43779 or bug 44083?

[Simon Fraser (smfr)]

The pattern is being drawn with the wrong CTM somehow.

[Simon Fraser (smfr)]

Maybe RenderSVGResourcePattern::applyResource() needs to do a setPatternSpaceTransform() every time, in case scrolling has happened?

[Dirk Schulze]

(In reply to comment #11)
> Maybe RenderSVGResourcePattern::applyResource() needs to do a setPatternSpaceTransform() every time, in case scrolling has happened?

We still don't see this problem on other platforms. And they often repaint more regular than CG. IIRC patterns on CG don't have a patternspace or at least don't sync it with the context. Maybe this is the problem? But can't test or debug it here.

[Nikolas Zimmermann]

(In reply to comment #9)
> Related to bug 43779 or bug 44083?

43779 is not related, as it also happens with patterns that only consit of simple shapes (rect / circle...)
44083 is also not related, getScreenCTM is not used for painting patterns.

(In reply to comment #10)
> The pattern is being drawn with the wrong CTM somehow.

I'm not sure about that, if you just switch from the Safari window to another one, and switch back, it looks correct again.

I really wonder how the scrollview works at all, if quartz debug doesn't show any yellow repaint rectangles, while scrolling? Do you know this code?

[Simon Fraser (smfr)]

(In reply to comment #13)
> (In reply to comment #9)
> > Related to bug 43779 or bug 44083?
> 
> 43779 is not related, as it also happens with patterns that only consit of simple shapes (rect / circle...)
> 44083 is also not related, getScreenCTM is not used for painting patterns.
> 
> (In reply to comment #10)
> > The pattern is being drawn with the wrong CTM somehow.
> 
> I'm not sure about that, if you just switch from the Safari window to another one, and switch back, it looks correct again.

Not when scrolled. It's all offset.

I think there may be a separate bug with partial redraws of the pattern, since the offsets are different in the redraw strip when scrolling.

> I really wonder how the scrollview works at all, if quartz debug doesn't show any yellow repaint rectangles, while scrolling? Do you know this code?

It blits the visible part of the window, and does an invalidate for the revealed part.

[Matthew Delaney]

Simon and I were able to reproduce a similar (perhaps the same underlying) bug this morning on mac Chrome (6.0.472.63). Here are the steps to repro on Chrome:

Open testcase.
Resize window to smallest possible size.
Reload.
Resize window to be big enough to see entire svg filled path.
Result: It appears that the pattern's image gets clipped to a width and height of the window's width and height at the time of reloading the page.

[Matthew Delaney]

Created attachment 69502 [details]
Testcase2

Another testcase with a color wheel as the image instead that makes it a little easier to see the effect of the scrolling bug.

[Matthew Delaney]

And here's a link to the similar testcase that Niko was referring to earlier.
http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/pservers-pattern-01-b.html

[Adam Luikart]

I believe this issue currently affects Safari 5.1.3 (a regression from 5.1.2), but appears to be fixed in the nightly builds (7534.53.10, r108593).

I think these sites are also examples of the issue:
http://jsfiddle.net/HBmfg/
http://thirteen23.com

[Adam Luikart]

(In reply to comment #18)

Permalink to thirteen23 example, since we're disabling the affected UI elements for Safari 5.1.3 shortly:
http://safari-svg-regression.thirteen23.com

[Tim Horton]

(In reply to comment #19)
> (In reply to comment #18)
> 
> Permalink to thirteen23 example, since we're disabling the affected UI elements for Safari 5.1.3 shortly:
> http://safari-svg-regression.thirteen23.com

Indeed, this looks fixed; I'm guessing by http://trac.webkit.org/changeset/104356.