Closed Bug 776747 Opened 10 years ago Closed 10 years ago

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


(Core :: SVG, defect)

17 Branch
Not set



Tracking Status
firefox17 + fixed


(Reporter: mbrubeck, Assigned: jwatt)



(Keywords: perf, regression, Whiteboard: [qa-])


(1 file)

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.
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.
Attached patch patchSplinter 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+
Closed: 10 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.
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.