Bug 24130

Summary: Paint very slow when horizontally resizing (CSS gradient)
Product: WebKit Reporter: James Robinson <jamesr>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: farukates, hyatt, mitz, simon.fraser, zwarich
Priority: P2 Keywords: HasReduction, InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://www.apple.com/safari/features.html
Attachments:
Description Flags
Reduced testcase
none
Another reduction
none
Intersect the destination rect passed to darwTiledImage() with the dirty rect
none
Intersect the destination rect passed to darwTiledImage() with the dirty rect simon.fraser: review+

Description James Robinson 2009-02-24 11:25:01 PST
When viewing the page: http://www.apple.com/safari/features.html vertical resizes are taking a very long time (500ms+, sometimes multiple seconds) which causes the entire browser to seize up, the window to go white, etc.  

Instrumentation points to the time being spent in ScrollView::paint() and children.  Layout time is very very short, it appears there's something horrible going on in the rasterizing code.

This behavior appears on the Windows and Mac WebKit nightlies, Safari 4 beta on Windows and Mac, and in the Chromium port.
Comment 1 Cameron Zwarich (cpst) 2009-02-24 11:26:30 PST
A similar thing occurs with full-screen zoom.
Comment 2 Mark Rowe (bdash) 2009-02-24 12:28:08 PST
<rdar://problem/6618196>
Comment 3 James Robinson 2009-02-24 13:55:20 PST
Created attachment 27932 [details]
Reduced testcase

The critical bits are:

*) background: -webkit-gradient
*) lots of text on a fixed-width element
*) resizing the window to smaller than the width of the text-containing element, forcing a clip.

It appears to perform worse on OS X compared to Safari 4 beta on Windows or Chromium.
Comment 4 mitz 2009-02-24 16:13:16 PST
Created attachment 27941 [details]
Another reduction

A smaller reduction. The border is critical.
Comment 5 mitz 2009-02-24 16:27:47 PST
The problem seems to happen when Image::drawTiled() chooses to call GeneratedImage::drawPattern() instead of GeneratedImage::draw(), namely when the destination rect is not contained in the tile rect. GeneratedImage::drawPattern() proceeds to allocate a potentially huge image buffer, draw into it, create an image out of it (copying the data in the process), and then use that image as a pattern.
Comment 6 mitz 2009-02-25 16:37:51 PST
Created attachment 27996 [details]
Intersect the destination rect passed to darwTiledImage() with the dirty rect
Comment 7 mitz 2009-02-25 16:59:04 PST
Comment on attachment 27996 [details]
Intersect the destination rect passed to darwTiledImage() with the dirty rect

Going to add a test case
Comment 8 mitz 2009-02-25 17:09:40 PST
Created attachment 27997 [details]
Intersect the destination rect passed to darwTiledImage() with the dirty rect
Comment 9 Simon Fraser (smfr) 2009-02-25 17:19:35 PST
Comment on attachment 27997 [details]
Intersect the destination rect passed to darwTiledImage() with the dirty rect

r-me
Comment 10 mitz 2009-02-25 17:25:19 PST
Fixed in <http://trac.webkit.org/changeset/41238>. See also bug 24178.
Comment 11 Simon Fraser (smfr) 2009-04-23 23:03:08 PDT
*** Bug 24956 has been marked as a duplicate of this bug. ***