Closed Bug 698996 Opened 9 years ago Closed 9 years ago

Firefox painfully slow rendering SVG elements


(Core :: SVG, defect)

Not set





(Reporter: diafygi, Unassigned)




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

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928224508

Steps to reproduce:

Perform the SVG rendering benchmark here:

Actual results:

62.690 sec  -  Firefox 7.0.1 
 3.923 sec  -  Chromium 14.0.835.202

Expected results:

Firefox should not take 16x longer to render the same number of SVG elements.

Others please verify the severe delays in Firefox.
13.243s - Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0a1) Gecko/20111101 Firefox/10.0a1 

I get a time about double on Firefox 7. Checking a current nightly that has some large JS improvements would be good.
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Related to or a dupe of bug 614564?
Just downloaded the nightly for comparison on the same machine (Acer Revo 3700)

Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:10.0a1) Gecko/20111028 Firefox/10.0a1

57.413 sec  -  Firefox 10.0a1

Not really that much of an improvement.
Depends on: 629200
This appears to be fixed by bug 629200.
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Keywords: perf
after bug 629200 land.

  20 - IE9
  20 - Opera 12 Build 1293: 
 642 - Firefox Nightly
1158 - Chrome 19
The work in bug 734079 has improved on things again by another order of magnitude. Here's what I'm seeing with Mac nightlies...

First, Brian's work on bug 629200. The pre- and post-change nightlies that I tested were:

Pre: cset a853f4017192:

Post: cset 2271cb92cc05:

The testcase time went from ~13.5s to ~0.560s, which is about a 25x speedup.

I then see a slight slowdown to ~0.745s between the following nightlies (I'm not sure what caused that):

cset ee554888d071

cset 9989b866c3a8

My work in bug 734079 came after that, with the before and after nightlies being:

cset 4bdae514b9be

cset 5c13fce74f83

This takes the time from ~0.745s to ~0.068s, which is roughly an 11x speedup.

So overall, with the work in bug 629200 and bug 734079, we've gone from ~13.5s to ~0.068s for this testcase, which is roughly a 200x speed up. :)
Version: 7 Branch → Trunk
Depends on: 734079
I'd like to assert that this is fixed. If a 200x speedup doesn't do it, I don't know what else to do here.
(In reply to Jet Villegas (:jet) from comment #7)
> I'd like to assert that this is fixed. If a 200x speedup doesn't do it, I
> don't know what else to do here.

Sounds good to me too. 
With the benchmark on the 1st comment :

FF Nightly goes ±57 ms
Opera Next goes ±27 ms (x2 faster than FFN)
Chrome Canary goes ±770 ms (x13.5 slower than FFN)
FIXED per comment 8. Thanks!
Closed: 9 years ago
Resolution: --- → FIXED
  I was told there are new SVG speedups in nightly. I have simple SVG file that has panning and zooming which is "terribly" slow and unusable in firefox. Tested in nightly. Reproducible. In google chrome, it is fast and snappy, but I'd rather come back to firefox for my needs. I can't post the test file publicly, but will send to a dev if you want to see how slow it is. It takes more than a second or two just to pan and zoom...I'm on 64bit linux.

Darren, please file a new bug using:

and attach your testcase using the "Add an attachment" link. Thanks!
Whiteboard: [in-the-wild] [external-report]
You need to log in before you can comment on or make changes to this bug.