Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Talos Regression :( SVG, Opacity Row Major increase 4.54%

RESOLVED FIXED in Firefox 17



5 years ago
5 years ago


(Reporter: mbrubeck, Assigned: jwatt)


({perf, regression})

17 Branch
perf, regression

Firefox Tracking Flags

(firefox17+ fixed)


(Whiteboard: [qa-])


(1 attachment)



5 years ago
It looks like this regression was probably caused by bug 614732:

Regression  SVG, Opacity Row Major increase 4.54% on MacOSX 10.7 Mozilla-Inbound
    Previous: avg 96.900 stddev 0.563 of 30 runs up to revision a746aaa32b22
    New     : avg 101.300 stddev 0.570 of 5 runs since revision 20ba830b7dca
    Change  : +4.400 (4.54% / z=7.812)
    Graph   :

Changeset range:
I can reproduce this running Talos locally with the following nightlies, but I'm not finding the output from the built-in profiler to be of much use in figuring out what's taking longer.


As far as builds I create locally go, I've not been able to reproduce it at all yet. I've tried creating opt builds with various config flags.
Assignee: nobody → jwatt
Current suspect is the last minute change in bug 614732 comment 79 to make nsSVGPathGeometryFrame::IsSVGTransformed return true if GetAnimatedTransformList() returns a non-null pointer without checking if the object pointed to has zero length. That means that we will _always_ return true from IsSVGTransformed, since nsSVGGraphicElement::GetAnimatedTransformList() always returns a non-null pointer. :-/

nsSVGDisplayContainerFrame::IsSVGTransformed and nsSVGForeignObjectFrame::IsSVGTransformed also don't check whether the list is empty.
tracking-firefox17: --- → +
I finally managed to coerce Try into giving me Talos results:

The IsSVGTransformed issue does indeed seem to be the problem, since that Try run actually resulted in a marginal pref improvement over the fastest result in the historic range used by

There are two ways to fix this.

 1) Have the GetAnimatedTransformList implementations return nsnull if the
    'transform' attribute is not actually set.

 2) Have the IsSVGTransformed callers of GetAnimatedTransformList check the
    object that it returns to see if it has zero length.

Option 1 is complicated by the way that the DOM wrappers require an object to be returned. Option 2 is complicated by the fact that we need to reconstruct the frame tree when we switch from not-transformed to transformed.
Created attachment 647025 [details] [diff] [review]

This patch makes GetAnimatedTransformList only allocate a gfxMatrix for elements when we need one. I.e. when:

 * the 'transform' attribute is set
 * the 'transform' attribute is animated
 * script is accessing the DOM wrapper (wrappers assume the internal
   object exists)
Attachment #647025 - Flags: review?(roc)
(In reply to Jonathan Watt [:jwatt] from comment #4)
> This patch makes GetAnimatedTransformList only allocate a gfxMatrix for

Comment on attachment 647025 [details] [diff] [review]

Review of attachment 647025 [details] [diff] [review]:

r+ with that.

::: content/svg/content/src/nsSVGElement.h
@@ +242,5 @@
>    }
>    // Despite the fact that animated transform lists are used for a variety of
>    // attributes, no SVG element uses more than one.
> +  virtual SVGAnimatedTransformList* GetAnimatedTransformList(
> +                                                     bool aAllocate = false) {

boolean parameters suck. Take a flags parameter and use an enum to define its values. E.g. enum { FORCE_ALLOCATE = 0x01 }, GetAnimatedTransformList(PRUint32). And document what it means!
Attachment #647025 - Flags: review?(roc) → review+
Target Milestone: --- → mozilla17

Comment 8

5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED
Comment 0 states that the previous average was 96.9, and shows the last four builds since the merge as averaging at 95.9, so it looks like this has more than fixed the perf regression.


5 years ago
status-firefox17: --- → fixed
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.