Closed Bug 614564 Opened 9 years ago Closed 7 years ago

SVG processing inefficiencies compared to Chromium

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: joeytwiddle, Unassigned)

References

()

Details

(Keywords: perf, Whiteboard: [in-the-wild] [external-report])

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
Keywords: perf
Product: Firefox → Core
QA Contact: general → general
Whiteboard: [Profiling needed]
Version: unspecified → Trunk
> 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...
Status: UNCONFIRMED → NEW
Component: General → SVG
Ever confirmed: true
QA Contact: general → general
Summary: Audio processing inefficiencies compared to Chromium → SVG processing inefficiencies compared to Chromium
Whiteboard: [Profiling needed]
Oh, all the audio-related stuff adds up to about 1.5% of total time.
roc, would the display list analysis let us stop doing those invalidates on insert/remove for SVG?
> A quarter is the GetLocalizedStringPref calls

Filed bug 614723.

> createElementNS; this should be quickstubbed.

Filed bug 614724.
Depends on: 614723, 614724
(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.
I filed 614732 for SVG display lists (including display-list-based invalidation).
Depends on: 614732
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [in-the-wild] [external-report]
You need to log in before you can comment on or make changes to this bug.