RESOLVED FIXED 24130
Paint very slow when horizontally resizing (CSS gradient) 
https://bugs.webkit.org/show_bug.cgi?id=24130
Summary Paint very slow when horizontally resizing (CSS gradient)
James Robinson
Reported 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.
Attachments
Reduced testcase (64.17 KB, text/html)
2009-02-24 13:55 PST, James Robinson 		no flags
Details
Another reduction (170 bytes, text/html)
2009-02-24 16:13 PST, mitz 		no flags
Details
Intersect the destination rect passed to darwTiledImage() with the dirty rect (1.74 KB, patch)
2009-02-25 16:37 PST, mitz 		no flags
DetailsFormatted DiffDiff
Intersect the destination rect passed to darwTiledImage() with the dirty rect (103.24 KB, patch)
2009-02-25 17:09 PST, mitz 		simon.fraser: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Cameron Zwarich (cpst)
Comment 1 2009-02-24 11:26:30 PST
A similar thing occurs with full-screen zoom.
Mark Rowe (bdash)
Comment 2 2009-02-24 12:28:08 PST
<rdar://problem/6618196>
James Robinson
Comment 3 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.
mitz
Comment 4 2009-02-24 16:13:16 PST
Created attachment 27941 [details] Another reduction A smaller reduction. The border is critical.
mitz
Comment 5 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.
mitz
Comment 6 2009-02-25 16:37:51 PST
Created attachment 27996 [details] Intersect the destination rect passed to darwTiledImage() with the dirty rect
mitz
Comment 7 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
mitz
Comment 8 2009-02-25 17:09:40 PST
Created attachment 27997 [details] Intersect the destination rect passed to darwTiledImage() with the dirty rect
Simon Fraser (smfr)
Comment 9 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
mitz
Comment 10 2009-02-25 17:25:19 PST
Fixed in <http://trac.webkit.org/changeset/41238>. See also bug 24178.
Simon Fraser (smfr)
Comment 11 2009-04-23 23:03:08 PDT
*** Bug 24956 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.