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+

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
Another reduction (170 bytes, text/html)
2009-02-24 16:13 PST, mitz
no flags
Intersect the destination rect passed to darwTiledImage() with the dirty rect (1.74 KB, patch)
2009-02-25 16:37 PST, mitz
no flags
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+
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
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
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.