Bug 482402 (enablesmil)

Enable "svg.smil.enabled" pref by default

RESOLVED FIXED in mozilla1.9.3a1



10 years ago
7 years ago


(Reporter: dholbert, Assigned: dholbert)


(Blocks 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



10 years ago
No description provided.

Comment 1

10 years ago
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:
Blocks: acid3
Depends on: 473705, 473904
Summary: Enable svg.smil.enabled" → Enable "svg.smil.enabled" pref by default

Comment 2

10 years ago
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).
Depends on: 436296
Depends on: animateMotion
Depends on: 436276
Depends on: 474049
Depends on: 474739
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?

Comment 5

10 years ago
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)

Comment 6

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


10 years ago
OS: Linux → All
Hardware: x86 → All

Comment 7

10 years ago
Here's a patch to enable the pref by default (when we're ready).
Assignee: nobody → dholbert
(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.
Blocks: svg11tests
Alias: smil

Comment 10

10 years ago
Attachment #367113 - Attachment is obsolete: true
Attachment #407867 - Flags: review?(roc)

Comment 11

10 years ago
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Looks like this regressed tSVG by 1%. Does that seem possible?


10 years ago
Blocks: 470868

Comment 13

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

Comment 14

10 years ago
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


10 years ago
Alias: smil → enablesmil


10 years ago
Blocks: 532997
Depends on: 571863
You need to log in before you can comment on or make changes to this bug.