Closed Bug 482402 (enablesmil) Opened 15 years ago Closed 15 years ago

Enable "svg.smil.enabled" pref by default

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1

People

(Reporter: dholbert, Assigned: dholbert)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

      No description provided.
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
Blocks: acid3
Depends on: 473705, 473904
Summary: Enable svg.smil.enabled" → Enable "svg.smil.enabled" pref by default
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?
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*
OS: Linux → All
Hardware: x86 → All
Here's a patch to enable the pref by default (when we're ready).
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
(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
Attachment #367113 - Attachment is obsolete: true
Attachment #407867 - Flags: review?(roc)
Landed:
http://hg.mozilla.org/mozilla-central/rev/c5b353307fb8
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Looks like this regressed tSVG by 1%. Does that seem possible?
Blocks: 470868
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
Alias: smil → enablesmil
Blocks: 532997
Depends on: 571863
You need to log in before you can comment on or make changes to this bug.