WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
14003
WebKit invalidates *way* too much during JS based SVG animation
https://bugs.webkit.org/show_bug.cgi?id=14003
Summary
WebKit invalidates *way* too much during JS based SVG animation
Eric Seidel (no email)
Reported
2007-06-05 13:19:53 PDT
WebKit invalidates *way* too much during JS based SVG animation See Hixie's perf test. Watch how we end up redrawing the entire tiger every time, even though we should only be redrawing the area where the circle was before.
Attachments
fix (exposes a bug in text repaint code)
(2.83 KB, patch)
2007-09-30 19:49 PDT
,
Eric Seidel (no email)
no flags
Details
Formatted Diff
Diff
fix (and avoids bad RenderBlock code)
(8.41 KB, patch)
2007-10-05 17:25 PDT
,
Eric Seidel (no email)
oliver
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2007-06-05 14:53:13 PDT
Ok, it turns out the problem is due to this line: while (child) { if (!child->isRenderPath() || static_cast<RenderPath*>(child)->hasRelativeValues()) child->setNeedsLayout(true); We end up causing any container child to re-layout, even when not necessary. Instead the RenderSVGContainer code needs to be smart enough to see if it's width/height has changed, and then (and only then) bother to mark it's relative-length path or container kids as needing layout.
Rob Buis
Comment 2
2007-08-18 13:16:06 PDT
(In reply to
comment #0
)
> WebKit invalidates *way* too much during JS based SVG animation > > See Hixie's perf test. Watch how we end up redrawing the entire tiger every > time, even though we should only be redrawing the area where the circle was > before. >
Seems fixed on fb? Cheers, Rob.
Eric Seidel (no email)
Comment 3
2007-08-19 12:44:28 PDT
Do you remember which patch had the fix? I've not been watching the checkins closely *at all* but closing this would require the "relayout every child when doing a layout" bug described above to have been fixed.
Eric Seidel (no email)
Comment 4
2007-09-26 12:14:44 PDT
The bad code still exists in RenderSVGContainer: while (child) { // FIXME: This check is bogus, see
http://bugs.webkit.org/show_bug.cgi?id=14003
if (!child->isRenderPath() || static_cast<RenderPath*>(child)->hasRelativeValues()) child->setNeedsLayout(true); line 243
Eric Seidel (no email)
Comment 5
2007-09-30 19:49:21 PDT
Created
attachment 16479
[details]
fix (exposes a bug in text repaint code) So this fixes our overzealous repainting, however it exposes a repaint bug in RenderSVGText's use of RenderBlock::layout(). RenderBlock::layout() will attempt to do a partial repaint when the block itself has not changed size. The calculations used for the partial repaint were initially not SVG transform aware (this patch fixes that), but even with this patch there seem to be int vs. float issues regarding those repaints. With this patch applied you can view the perf01.xml example with Quartz Debug's "Flash Screen Updates" enabled and see how as you resize the window *sometimes* the repaint rect overlaps with the changing text, and sometimes it doesn't. :( I should note that only RenderSVGRoot needs this change (to check if the bounds changed before forcing kids to layout), due to the fact that RenderSVGRoot determines its own bounds, and RenderSVGContainer does not (RenderSVGContainer's bounds are determined by its kids). Actually, as I type that, I realize that might not always be true. <g>'s bounds are determined by its kids, but other containers might determine their own bounds, in which case this change is still not quite correct.
Oliver Hunt
Comment 6
2007-10-05 00:04:24 PDT
Alas you patch destroys text input repainting :(
Eric Seidel (no email)
Comment 7
2007-10-05 17:25:55 PDT
Created
attachment 16555
[details]
fix (and avoids bad RenderBlock code)
Oliver Hunt
Comment 8
2007-10-05 17:52:16 PDT
Comment on
attachment 16555
[details]
fix (and avoids bad RenderBlock code) While this doesn't resolve all issues, it's certainly improved things dramatically
Eric Seidel (no email)
Comment 9
2007-10-05 18:12:46 PDT
Landed as
r26075
on the feature-branch
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