WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
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+
Details
Formatted Diff
Diff
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.
Top of Page
Format For Printing
XML
Clone This Bug