89475 – Blur filter causes issues when scrolling

RESOLVED FIXED 89475

Blur filter causes issues when scrolling

https://bugs.webkit.org/show_bug.cgi?id=89475

Summary Blur filter causes issues when scrolling

Keyar Hood

Reported 2012-06-19 08:37:36 PDT

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).

Attachments
Demonstrates the scrolling blur bug. No red should be visible if the scrolling worked. (1002 bytes, text/html) 2012-06-19 08:37 PDT, Keyar Hood	no flags	Details
Patch V1 (8.75 KB, patch) 2012-06-22 13:44 PDT, Alexandru Chiculita	webkit.review.bot: commit-queue-	Details Formatted Diff Diff
Archive of layout-test-results from ec2-cr-linux-01 (653.72 KB, application/zip) 2012-06-22 16:11 PDT, WebKit Review Bot	no flags	Details
Patch V2 (12.13 KB, patch) 2012-06-25 13:50 PDT, Alexandru Chiculita	simon.fraser: review+ simon.fraser: commit-queue-	Details Formatted Diff Diff
Patch V3 (9.53 KB, patch) 2012-06-26 16:58 PDT, Alexandru Chiculita	no flags	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Keyar Hood

Comment 1 2012-06-19 10:54:52 PDT

Note, the supplied test will not automatically work on Mac. You will have to manually scroll up then down to see the problem

Shane Stephens

Comment 2 2012-06-20 21:09:01 PDT

At least on the mac, this seems to be an issue more with failure to repaint rather than the scroll not working?

Alexandru Chiculita

Comment 3 2012-06-21 11:43:32 PDT

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.

Alexandru Chiculita

Comment 4 2012-06-21 18:16:48 PDT

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).

Stephen White

Comment 5 2012-06-22 07:16:31 PDT

(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.

Alexandru Chiculita

Comment 6 2012-06-22 09:49:24 PDT

(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.

Alexandru Chiculita

Comment 7 2012-06-22 13:44:38 PDT

Created attachment 149094 [details] Patch V1 Not the final patch, I'm using the EWS to collect the expected results.

WebKit Review Bot

Comment 8 2012-06-22 16:11:37 PDT

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

WebKit Review Bot

Comment 9 2012-06-22 16:11:53 PDT

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

Alexandru Chiculita

Comment 10 2012-06-25 13:50:52 PDT

Created attachment 149346 [details] Patch V2

Simon Fraser (smfr)

Comment 11 2012-06-25 14:48:16 PDT

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.

Alexandru Chiculita

Comment 12 2012-06-25 17:28:27 PDT

(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.

Simon Fraser (smfr)

Comment 13 2012-06-25 17:33:56 PDT

Maybe those ports haven't enabled mock scrollbars in DRT yet. They should!

Alexandru Chiculita

Comment 14 2012-06-26 11:37:06 PDT

(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.

Alexandru Chiculita

Comment 15 2012-06-26 16:58:41 PDT

Created attachment 149635 [details] Patch V3 Updated the test to use the mock scrollbars on all the platforms.

WebKit Review Bot

Comment 16 2012-06-27 10:38:23 PDT

Comment on attachment 149635 [details] Patch V3 Clearing flags on attachment: 149635 Committed r121348: <http://trac.webkit.org/changeset/121348>

WebKit Review Bot

Comment 17 2012-06-27 10:38:29 PDT

All reviewed patches have been landed. Closing bug.

Simon Fraser (smfr)

Comment 18 2012-06-27 10:52:55 PDT

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?

Alexandru Chiculita

Comment 19 2012-06-27 11:28:11 PDT

(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.

Note You need to log in before you can comment on or make changes to this bug.

Status RESOLVED

Resolution FIXED

Priority P2

Severity Normal

Classification Unclassified

Version 528+ (Nightly build)

Hardware Unspecified

OS Unspecified

Product WebKit

Component CSS

Assignee

Alexandru Chiculita

Reported

2012-06-19 08:37 PDT

Modified

2012-06-28 00:01 PDT History

CC List

11 users Show

URL

Keywords

Depends on

90091

Blocks

Dependencies

tree graph