I'm filing this bug on default-enabling the "svg.smil.enabled" pref, once we're sure that SVG Animation will be "ready for shipping" before the next release off of Trunk. See discussion about this topic on this newsgroup thread: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/4cf4cbdcbeeab7de

Note that it hasn't yet been decided what "ready for shipping" would include, but to start, it probably should include support for animating all SVG attributes (Bug 436276) and ideally CSS properties, too (Bug 474049).

I added 3 more bugs to list that that I thought should at least be looked at, and made them all block this bug. Feel free to remove them if you determine they don't really block flipping the pref.

(In reply to comment #3) > I added 3 more bugs to list that that I thought should at least be looked at, > and made them all block this bug. I took a look at the dependencies but didn't find any related issues... Did I miss something?

Helder: it's easiest to just look at the "History" look in the upper-right corner of this bug page -- that shows that Bill recently added bug 436296, bug 436418, and bug 474739 as dependencies. (along with the bugs I noted in comment 2)

(In reply to comment #5) > Helder: it's easiest to just look at the "History" look er, "History" *link*

Here's a patch to enable the pref by default (when we're ready).

(In reply to comment #5) > Helder: it's easiest to just look at the "History" look in the upper-right > corner of this bug page I saw the dependencies but somehow got the feeling they were lying there for a while already -- didn't remember to check the report's history. Thanks for the enlightenment! :-)

I was thinking on this further. There are really 3 buckets these bugs could fall into. 1. Bugs that you don't want to enable SMIL until they are fixed. 2. Bugs that you don't want to release a beta with SMIL enabled unless they are fixed. 3. Bugs you don't want to do an official release with SMIL enabled. Probably all of these should block a release and perhaps some block releasing a beta. I am not sure any of them warrant not enabling SMIL in a pre-alpha1 build to get more testing to make sure this does not cause other issues. So kind of a mark all these as blocking next release, fix any that belong in bucket1 then flip the pref and prioritize the remaining bugs for where in the release cycle they need to be fixed.

Landed: http://hg.mozilla.org/mozilla-central/rev/c5b353307fb8

Looks like this regressed tSVG by 1%. Does that seem possible?

Definitely seems possible, if tSVG uses pages with SVG animation elements, and/or SVG animation APIs.

Hmm, looks like comment 13 was off the mark -- looks like Talos doesn't use any animation. I just grabbed latest talos from CVS using this command[1]: > cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -d talos mozilla/testing/performance/talos ...and I examined the "talos/page_load_test/svg" directory (which "sample.config" says is used for tSVG I couldn't find any animation-related stuff there, using grep -ir animate, grep -ir pause, grep -ir currenttime, and grep -ir "<set". So, this isn't a result of using any SMIL elements/APIs. So, what could the tSVG hit be from, in that case? This bug's patch can only affected code that calls NS_SMILEnabled[2] (a getter for the about:config pref), and that's not very much code. My guess is that any perf hit would be due to calls to FlushAnimations[3]. That function is called from a number of places, and its behavior depends on SMIL being enabled because it uses "GetAnimationController()" (which returns null unless NS_SMILEnabled() is on). With no actual animation in the document, FlushAnimations has a pretty minimal impact, but I could see it having a small hit, since it's called in every nsSVGLength2 getter function and in nsSVGElement::GetAnimatedLengthValues. [1] source: https://wiki.mozilla.org/User:Standard8/Talos_Notes [2] http://mxr.mozilla.org/mozilla-central/ident?i=NS_SMILEnabled [3] http://mxr.mozilla.org/mozilla-central/search?string=flushanimations