614564 - SVG processing inefficiencies compared to Chromium

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Joey Twiddle]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

On a Pentium 4 under Debian stable, Chromium 9.0.574.0 (65192) gets a much better framerate from the above web page than Firefox 4 does.

I suspect this is either because the audio processing is taking more CPU under Firefox, or that the "audio thread" is not yielding often enough to the "visual thread", or both.

I say this because most purely-visual canvas effects perform better in Firefox 4 than in Chromium, so the audio must be the killer here.  (I get some acceleration from my nVidia GeForce FX 5200.)

Whichever browser I use, my CPU is maxxed out anyway.  Do you also notice the same framerate drop?

To fix this bug might require some profiling of where the CPU cycles are being spent, or why one thread is blocking the other.

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

> I say this because most purely-visual canvas effects

This page doesn't use canvas, fwiw.  It uses SVG.

A profile (on Mac, but given the data below I doubt Linux is all that different) shows:

 23% painting (about 2/5 of this being SVG paths)
 20% creating rendering objects ("frames").  Half of this is the UpdateGraphic
     invalidates we do on every frame insertion in SVG.  A quarter is the
     GetLocalizedStringPref calls from PassesConditionalProcessingTests(!).  A
     sixth is nsSVGElement::UpdateContentStyleRule.  The remaining tenth or so
     is everything else.
  3% cycle collection.
 12% setAttribute (at least 3/4 of this is under
     SVGAnimatedPathSegList::SetBaseValueString parsing the path data)
  4% overhead calling createElementNS; this should be quickstubbed.
  4% converting numbers to string and then concatenating for operator '+' on
     number and string in JS.
  3% appendChild calls.
  5% mjit-generated code
 17% removeChild calls.  Most of this (15% or more) is the invalidates that
     SVG does when a child frame is removed...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, all the audio-related stuff adds up to about 1.5% of total time.

Comment 3

[Boris Zbarsky [:bzbarsky]]

roc, would the display list analysis let us stop doing those invalidates on insert/remove for SVG?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> A quarter is the GetLocalizedStringPref calls

Filed bug 614723.

> createElementNS; this should be quickstubbed.

Filed bug 614724.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #3)
> roc, would the display list analysis let us stop doing those invalidates on
> insert/remove for SVG?

Yes, once we've converted SVG to use display lists. That is our immediate priority post-FF4.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I filed 614732 for SVG display lists (including display-list-based invalidation).

Comment 7

[Jonathan Watt [:jwatt]]

Link is now dead, but last I checked I didn't notice any pref issues any more on a cursory look. (The only reason I didn't close it at the time is because I was going to take a deeper look at invalidation at some point.) Closing as fixed since I believe the deps pretty much fixed this.