[Webkit-unassigned] [Bug 49437] SVGAnimations with IRI references via 'xlink:href' are slow

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 12 06:52:30 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=49437





--- Comment #9 from Nikolas Zimmermann <zimmermann at kde.org>  2010-11-12 06:52:30 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > I think it's part of this patch, as before your patch changing the target, would be immediately cause a new targetElement() to be returned,, which is not the case anymore.
> > (I'm sure that would reveal other bugs, but still..)
> 
> Hm, you're right, there might be some scenarios:
> * simple example, the animated value changed by JS (IIRC the spec wants us to proceed the animation and set the baseVal afterwards, take a look at it)
Yes, but that's another issue, hightly related to the fact that we're animating baseVal at the moment.... no way to fix that, w/o adding "proper" animVal support.

> * the animation is a children of the target and we change the hierarchy in the DOM. I would expect that the animation stops or, that the old parent still gets animated till the animation stoped.
Very true, didn't think about that one.

> * the IRI of the target changed, or more worst, another element gets the id of our current target. This is a bit more complicated and will not work with this patch. Not sure how we could handle it at all. Maybe we use the Resource handler to give back changes to the animation API. hmm..
Hm, indeed really tricky. With your patch, the target element could change the ID, and the animation wouldnt't be affected (it would just go on), so it would be even better than the current behaviour (maybe just write a test for that..)

If an element <x> is animated, and it's id changes, it has to notify all SVGAnimate*Elements about this change (triggered from eg. SVGElement::svgAttributeChanged, when 'id' changes), similar to what we do when the id changes, that SVGResourcesCache gets updated... but that's really out of scope for this patch.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list