-webkit-gradient slows down scrolling when page has horizontal scrollbar

[Jon Honeycutt]

The site above has very slow scrolling. Not reproducible in Opera. Site uses some WebKit-specific CSS that could be responsible. Disabling styles results in normal scrolling speed.

[Mark Rowe (bdash)]

<rdar://problem/6020083>

[Adam Bryzak]

(In reply to comment #0)
> The site above has very slow scrolling. Not reproducible in Opera. Site uses
> some WebKit-specific CSS that could be responsible. Disabling styles results in
> normal scrolling speed.
> 

The slow vertical scrolling only seems to happen for me when the horizontal scrollbar is not scrolled completely to the left. As soon as the page is scrolled 1px horizontally, the vertical scrolling slows down considerably. If the horizontal scrollbar is on the left the vertical scrolling is fine. It also happens on http://www.apple.com/safari/whats-new.html

[Ryosuke Niwa]

Created attachment 31144 [details]
simplified version of http://www.apple.com/safari/whats-new.html

this reproduces the bug in Safari 4 (Windows 528.17) but the effect cannot be experienced (by human) in Chrome 3.0.183.1.

[Ryosuke Niwa]

Created attachment 31145 [details]
sample HTML copied from http://www.apple.com/safari/whats-new.html

This HTML reproduces the bug both in Chrome and Safari.  The bug disappears when -webkit-gradient is removed.

[Eric Seidel (no email)]

Hyatt wrote the scroll code and the gradient code. :)

[Eric Seidel (no email)]

Created attachment 31147 [details]
reduced test case

[Eric Seidel (no email)]

This does not reproduce for me on a TOT Debug build.

[Eric Seidel (no email)]

This may have been fixed since Safari 4?

[Adam Bryzak]

I tested it using Safari 4 final and with the latest WebKit running on OS X 10.5.7

[Ryosuke Niwa]

WebKit build 44547 on Windows reproduced the problem with the reduced test case.

[Eric Seidel (no email)]

Wow.  This still reproduces on TOT, but I only notice it in Release builds!

This is similar to bug 24130. GeneratedImage::drawPattern() is used to draw the gradient rather than GeneratedImage::draw(), the reason being that, even with the fix for bug 24130, the rect to paint legitimately contains more than one tile. As mentioned in that bug, the way to address this is probably by way of bug 24178.

There are other possible optimizations for vertical and horizontal gradients (adjusting the tile dimensions in the direction perpendicular to the gradient; won’t help with the “reduced test case” attached to this bug, but should help with the What’s New page, for example).

[Simon Fraser (smfr)]

I gather this is on Mac and Windows?

[Ryosuke Niwa]

(In reply to comment #14)
> I gather this is on Mac and Windows?
> 

Yes, we have observed it on Mac and Windows.  But it may still reproduce in Linux.

Created attachment 46638 [details]
Use 1-by-n tiles for horizontal and vertical linear gradients

[Simon Fraser (smfr)]

Comment on attachment 46638 [details]
Use 1-by-n tiles for horizontal and vertical linear gradients

> Index: WebCore/platform/graphics/Generator.h
> ===================================================================

>      virtual void fill(GraphicsContext*, const FloatRect&) = 0;
> +    virtual void adjustParametersForTiledDrawing(IntSize& /* size */, FloatRect& /* srcRect */, TransformationMatrix& /* patternTransform */, FloatPoint& /* phase */) { 

Maybe remove patternTransform and phase from this method if you think they will never be used. They can easily be added if we find a use.

r=me

Fixed in <http://trac.webkit.org/projects/webkit/changeset/53318>

[Dimitri Glazkov (Google)]

Committed r53816: <http://trac.webkit.org/changeset/53816>