Bug 44635 - Scrolling causes image pattern fill to be rendered incorrectly
Summary: Scrolling causes image pattern fill to be rendered incorrectly
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Tim Horton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-25 14:20 PDT by sprite+b.w.o
Modified: 2012-02-23 10:31 PST (History)
5 users (show)

See Also:


Attachments
Testcase for the bug (377.14 KB, application/zip)
2010-08-25 14:20 PDT, sprite+b.w.o
no flags Details
Screenshot for pattern fill image corruption (151.90 KB, image/png)
2010-08-25 15:18 PDT, sprite+b.w.o
no flags Details
Testcase2 (62.43 KB, application/zip)
2010-10-01 12:29 PDT, Matthew Delaney
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description sprite+b.w.o 2010-08-25 14:20:59 PDT
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
Comment 1 Matthew Delaney 2010-08-25 14:46:54 PDT
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!
Comment 2 sprite+b.w.o 2010-08-25 14:57:48 PDT
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
Comment 3 Dirk Schulze 2010-08-25 15:05:12 PDT
(In reply to comment #2)
Works for me on Chromium and WebKitGtk, no corruptions.
Comment 4 Dirk Schulze 2010-08-25 15:10:17 PDT
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?
Comment 5 sprite+b.w.o 2010-08-25 15:18:29 PDT
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.
Comment 6 Nikolas Zimmermann 2010-08-26 00:34:23 PDT
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 :(
Comment 7 Simon Fraser (smfr) 2010-08-27 08:49:24 PDT
Repaint issue?
Comment 8 Nikolas Zimmermann 2010-08-27 08:56:28 PDT
(In reply to comment #7)
> Repaint issue?

Quartz debug shows nothing is repainted, while scrolling. Do you have any clue what might cause this?
Comment 9 Simon Fraser (smfr) 2010-08-27 09:04:36 PDT
Related to bug 43779 or bug 44083?
Comment 10 Simon Fraser (smfr) 2010-08-27 11:50:59 PDT
The pattern is being drawn with the wrong CTM somehow.
Comment 11 Simon Fraser (smfr) 2010-08-27 12:00:20 PDT
Maybe RenderSVGResourcePattern::applyResource() needs to do a setPatternSpaceTransform() every time, in case scrolling has happened?
Comment 12 Dirk Schulze 2010-08-27 12:28:15 PDT
(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.
Comment 13 Nikolas Zimmermann 2010-08-27 12:59:06 PDT
(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?
Comment 14 Simon Fraser (smfr) 2010-08-27 13:22:41 PDT
(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.
Comment 15 Matthew Delaney 2010-09-28 14:57:06 PDT
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.
Comment 16 Matthew Delaney 2010-10-01 12:29:22 PDT
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.
Comment 17 Matthew Delaney 2010-10-01 15:30:51 PDT
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
Comment 18 Adam Luikart 2012-02-23 10:26:19 PST
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
Comment 19 Adam Luikart 2012-02-23 10:28:51 PST
(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
Comment 20 Tim Horton 2012-02-23 10:31:07 PST
(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.