Closed Bug 698996 Opened 8 years ago Closed 8 years ago
Firefox painfully slow rendering SVG elements
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: http://bl.ocks.org/1296930 Actual results: 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. http://nightly.mozilla.org
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.
This appears to be fixed by bug 629200.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
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: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/02/2012-02-16-03-12-31-mozilla-central/firefox-13.0a1.en-US.mac.dmg Post: cset 2271cb92cc05: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/02/2012-02-17-03-12-27-mozilla-central/firefox-13.0a1.en-US.mac.dmg 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 https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-20-04-35-30-mozilla-central/firefox-14.0a1.en-US.mac.dmg cset 9989b866c3a8 https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-20-09-12-59-mozilla-central/firefox-14.0a1.en-US.mac.dmg My work in bug 734079 came after that, with the before and after nightlies being: cset 4bdae514b9be https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-21-03-11-51-mozilla-central/firefox-14.0a1.en-US.mac.dmg cset 5c13fce74f83 https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-22-03-12-20-mozilla-central/firefox-14.0a1.en-US.mac.dmg 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
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!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Hi, 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. thanks,
Darren, please file a new bug using: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=SVG and attach your testcase using the "Add an attachment" link. Thanks!
You need to log in before you can comment on or make changes to this bug.