RESOLVED FIXED 11720
REGRESSION: large amounts of CPU consumed viewing this site 
https://bugs.webkit.org/show_bug.cgi?id=11720
Summary REGRESSION: large amounts of CPU consumed viewing this site
Rachael Worthington (cheers)
Reported 2006-11-29 17:45:10 PST
go to the above link in OmniWeb or the lates WebKit nightly, and watch your CPU consumption. It rockets up, and stays high, until you hide the page by opening a new tab over it. (being in a background tab it doesn't consume silly amounts of processing time, but hidden and in a front-most tab it does. I'm attaching a sample as well.
Attachments
Sample of Webkit Misbehaving (79.90 KB, text/plain)
2006-11-29 17:46 PST, Rachael Worthington (cheers) 		no flags
Details
Invalidate only the area where the updated image paints. Also fixes bug 5399. (33.62 KB, patch)
2007-02-01 14:50 PST, mitz 		hyatt: review-
DetailsFormatted DiffDiff
Binaries part of the patch (931.40 KB, application/octet-stream)
2007-02-01 14:59 PST, mitz 		no flags
Details
Invalidate only the area where the updated image paints. Also fixes bug 5399 and bug 5821. (40.81 KB, patch)
2007-02-02 01:21 PST, mitz 		hyatt: review+
DetailsFormatted DiffDiff
Binaries part of the patch (932.12 KB, application/octet-stream)
2007-02-02 01:23 PST, mitz 		no flags
Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Rachael Worthington (cheers)
Comment 1 2006-11-29 17:46:01 PST
Created attachment 11675 [details] Sample of Webkit Misbehaving
mitz
Comment 2 2006-11-30 11:58:38 PST
A huge part of the page is constantly repainting at 10fps due to one or two elements having a small animated gif as their non-repeating background image. Something like: <div style="height: 500px; background: url(http://www.wowhead.com/images/loading2.gif) no-repeat"></div> causes the entire div to repaint on each animation frame. Note that the background is non-repeating, so there's no reason to repaint the whole area. Shipping Safari repaints only the 16x16 area that animates.
Dave Hyatt
Comment 3 2006-11-30 12:09:52 PST
This is fallout from having a real animation observer architecture. That the old way worked more efficiently was largely coincidental. RenderObjects will have to study their background geometry and be smarter about what they repaint when they get told that a new animation frame is available.
Mark Rowe (bdash)
Comment 4 2007-01-28 19:12:57 PST
<rdar://problem/4960272>
mitz
Comment 5 2007-02-01 14:50:33 PST
Created attachment 12861 [details] Invalidate only the area where the updated image paints. Also fixes bug 5399.
mitz
Comment 6 2007-02-01 14:59:06 PST
Created attachment 12862 [details] Binaries part of the patch
Dave Hyatt
Comment 7 2007-02-01 16:10:57 PST
Comment on attachment 12861 [details] Invalidate only the area where the updated image paints. Also fixes bug 5399. (1) Inline flows need to be handled (if they're broken up across multiple lines). (2) Would it be better to put the table checks into imageChanged overrides in the table code itself? (3) Change the htmlTag/bodyTag stuff to isRoot()/isBody().
mitz
Comment 8 2007-02-02 01:21:12 PST
Created attachment 12868 [details] Invalidate only the area where the updated image paints. Also fixes bug 5399 and bug 5821. Addressed Hyatt's comments: inline flows do a full repaint; table parts handled by overrides, also changed <col> to repaint the whole table instead of nothing, fixing bug 5821; changed to use isBody() and isRoot().
mitz
Comment 9 2007-02-02 01:23:37 PST
Created attachment 12869 [details] Binaries part of the patch
Dave Hyatt
Comment 10 2007-02-07 02:18:59 PST
Comment on attachment 12868 [details] Invalidate only the area where the updated image paints. Also fixes bug 5399 and bug 5821. r=me
Mark Rowe (bdash)
Comment 11 2007-02-07 21:06:01 PST
Landed in r19490.
Mark Rowe (bdash)
Comment 12 2007-02-11 23:17:35 PST
Binary bits were in r19570.
Note You need to log in before you can comment on or make changes to this bug.