| Summary: | Blur filter causes issues when scrolling | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Keyar Hood <keyar> | ||||||||||||
| Component: | CSS | Assignee: | Alexandru Chiculita <achicu> | ||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||
| Severity: | Normal | CC: | achicu, dglazkov, dino, jamesr, keyar, mitz, senorblanco, shanestephens, simon.fraser, thorton, webkit.review.bot | ||||||||||||
| Priority: | P2 | ||||||||||||||
| Version: | 528+ (Nightly build) | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Bug Depends on: | 90091 | ||||||||||||||
| Bug Blocks: | |||||||||||||||
| Attachments: |
|
||||||||||||||
Note, the supplied test will not automatically work on Mac. You will have to manually scroll up then down to see the problem At least on the mac, this seems to be an issue more with failure to repaint rather than the scroll not working? I think this happens because of the subpixel layout. The issue doesn't seem to reproduce in Safari. I think that adding some pixelSnappedIntRect would fix the issue. I will take a look. Sorry I was looking at the wrong Chromium build. The real issue is that Chromium is doing a blit when scrolling instead of repainting the area. I think we need disable scrolling by blitting when there are elements with filters. We only need to do that for blur and drop-shadow (filters with outsets). (In reply to comment #3) > I think this happens because of the subpixel layout. The issue doesn't seem to reproduce in Safari. I think that adding some pixelSnappedIntRect would fix the issue. I will take a look. Just FYI, I was able to repro this in Safari (WebKit nightly), although it may not be captured by this test case. Simply open Facebook or Google+, apply a -webkit-filter: blur(1px); to the <body> element, and scroll. (In reply to comment #5) > (In reply to comment #3) > > I think this happens because of the subpixel layout. The issue doesn't seem to reproduce in Safari. I think that adding some pixelSnappedIntRect would fix the issue. I will take a look. > > Just FYI, I was able to repro this in Safari (WebKit nightly), although it may not be captured by this test case. Simply open Facebook or Google+, apply a -webkit-filter: blur(1px); to the <body> element, and scroll. You're right. I was trying in a Chrome Dev build and the only thing I've seen were some white lines around the repaint rectangles, so I thought it was from the subpixel. That issue seems to be fixed in the nightly. The current issue is from the the FrameView scrolling mechanism which is trying to move things around while scrolling instead of repainting. That only happens when it is possible to be done, but in this case it is not possible. I will post a patch today. Created attachment 149094 [details]
Patch V1
Not the final patch, I'm using the EWS to collect the expected results.
Comment on attachment 149094 [details] Patch V1 Attachment 149094 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13029545 New failing tests: css3/filters/blur-filter-page-scroll.html Created attachment 149129 [details]
Archive of layout-test-results from ec2-cr-linux-01
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Created attachment 149346 [details]
Patch V2
Comment on attachment 149346 [details] Patch V2 View in context: https://bugs.webkit.org/attachment.cgi?id=149346&action=review > LayoutTests/ChangeLog:15 > + * platform/chromium-linux/css3/filters/blur-filter-page-scroll-expected.png: Added. > + * platform/chromium-linux/css3/filters/blur-filter-page-scroll-expected.txt: Added. > + * platform/chromium-mac/css3/filters/blur-filter-page-scroll-expected.png: Added. > + * platform/chromium-mac/css3/filters/blur-filter-page-scroll-expected.txt: Added. Are these platforms not using mock scrollbars? The images show platform scrollbars, which is bad. (In reply to comment #11) > (From update of attachment 149346 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=149346&action=review > > > LayoutTests/ChangeLog:15 > > + * platform/chromium-linux/css3/filters/blur-filter-page-scroll-expected.png: Added. > > + * platform/chromium-linux/css3/filters/blur-filter-page-scroll-expected.txt: Added. > > + * platform/chromium-mac/css3/filters/blur-filter-page-scroll-expected.png: Added. > > + * platform/chromium-mac/css3/filters/blur-filter-page-scroll-expected.txt: Added. > > Are these platforms not using mock scrollbars? The images show platform scrollbars, which is bad. If they do, I don't know how to trigger them. This is what the new-run-webkit-test generated. Do you know how to generate that? I didn't do anything special for WebKit Mac to use the mock scrollbars. Maybe those ports haven't enabled mock scrollbars in DRT yet. They should! (In reply to comment #13) > Maybe those ports haven't enabled mock scrollbars in DRT yet. They should! I've asked on IRC and it seems like there's a window.internals API that enables mock scrollbars. I will use that and post a new patch. Created attachment 149635 [details]
Patch V3
Updated the test to use the mock scrollbars on all the platforms.
Comment on attachment 149635 [details] Patch V3 Clearing flags on attachment: 149635 Committed r121348: <http://trac.webkit.org/changeset/121348> All reviewed patches have been landed. Closing bug. Comment on attachment 149635 [details] Patch V3 View in context: https://bugs.webkit.org/attachment.cgi?id=149635&action=review > Source/WebCore/page/FrameView.cpp:1473 > + if (renderBox->layer() && renderBox->layer()->parent()) { > + RenderBoxModelObject* renderer = renderBox->layer()->parent()->renderer(); > + if (renderer->style()->hasFilterOutsets()) { > + // If the fixed layer has a blur/drop-shadow filter applied on its parent, we cannot > + // scroll using the fast path, otherwise the outsets of the filter will be moved around the page. > + return false; > + } > + } Actually, doesn't this have to check all ancestors? (In reply to comment #18) > (From update of attachment 149635 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=149635&action=review > > > Source/WebCore/page/FrameView.cpp:1473 > > + if (renderBox->layer() && renderBox->layer()->parent()) { > > + RenderBoxModelObject* renderer = renderBox->layer()->parent()->renderer(); > > + if (renderer->style()->hasFilterOutsets()) { > > + // If the fixed layer has a blur/drop-shadow filter applied on its parent, we cannot > > + // scroll using the fast path, otherwise the outsets of the filter will be moved around the page. > > + return false; > > + } > > + } > > Actually, doesn't this have to check all ancestors? Yes it seems like it needs to check all the ancestors. I've added https://bugs.webkit.org/show_bug.cgi?id=90087 to fix that. |
Created attachment 148340 [details] Demonstrates the scrolling blur bug. No red should be visible if the scrolling worked. Having blur on the entire page will result in incorrect rendering when the page is scrolled if one div is scrolled underneath another. Set a <div> tag set to use "-webkit-filter: blur(#px)" where # is any number, including zero. Within this div, have two divs such that one will scroll underneath the other (such as having one with fixed position). Give the child divs two separate background colours. Scroll the page and the rendering will be incorrect. See attached file for an example page that displays this problem (if there was no issue, the page will not have red).