313998 - svg rendering performance

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[ced.dupont]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

I working on a xul application which generates a svg tree. I notice the performance are twice slower since the Firefox 1.5 beta 2 (included).
I just did the test with the nightly build and I've got exactly the same result.

Reproducible: Always

Steps to Reproduce:
The first way to feel it, open a svg document where you can move elements with the mouse. You will notice it's a little bit sticky.
The second way, I mesure the time spend to construct and display the svg tree. It's twice slower:
 "Firefox Setup 1.5 Beta 1.exe" : 375ms to display
 "Firefox Setup 1.5 Beta 2.exe" : 604ms to display
My test application is rigourously the same for this two tests.

Comment 1

[Martijn Wargers (dead)]

Could you attach a testcase/url that shows the problem?

Comment 2

[ced.dupont]

Attachment: html with embbeded svg

Try to move the boxes by dragging them.
You will see that the refresh rate is much slower.
I think there is something in the DOM access.

Comment 3

[ced.dupont]

Attachment: Count how many times we can move a svg element in 1 second

First, I did the test on a dummy DOM attribute. In one second I set attributes 45000 times. DOM access is not affected.

Second, I translate on x coordonate a SVG element.
Firefox 1.5 beta 1: 2841 move
Firefox 1.5 beta 2: 385 move

Comment 4

[ced.dupont]

I tried on Firefox 1.5rc2.
I did 821 moves, it's better than beta 2 but still less performant than beta 1.
I hope it will be fix. It will be a pity if the new svg feature can demonstrate it's real power.
I will help anybody to solve the problem, but I've not enough background on mozilla to do it on my own.

Comment 5

[ced.dupont]

Firefox 1.5rc3: 912 moves

Comment 6

[Timmy Brolin]

Here is another example: http://www.brolinembedded.se/misc/erlandsson.svg
This SVG can be moved around using the mouse (dragging).
It can also be zoomed in (click) and zoomed out (hold shift while clicking).

Out of Firefox, Opera and the Adobe SVG plugin for IE, Firefox is the slowest implementation.
But all three implementations have less than impressive performance.

Ideally, moving around SVG objects should be entirely smooth...

Comment 7

[ced.dupont]

To have a performance reference, I did the test "count the number of move in 1" seconds with Opera 8.02 .

I've got 33991 moves ! Pretty fast !

Comment 8

[ced.dupont]

Is this bug an issue ?
Do you think speed up svg rendering is not thinkable ?
Do you think it cannot be a great feature ?

I'm just wondering about the future of firefox and to the fact that SVG application built with Firefox got a real handicap.
Am I alone to consider this issue ?

Comment 9

[Jaroslav Zaruba]

(In reply to comment #8)
> Is this bug an issue ?
> Do you think speed up svg rendering is not thinkable ?
> Do you think it cannot be a great feature ?
> 
> I'm just wondering about the future of firefox and to the fact that SVG
> application built with Firefox got a real handicap.
> Am I alone to consider this issue ?
> 

I do agree and vote for this bug. I just have had to rewrite one quite simple GUI-component that I originally wrote in SVG into 'good old' HTML with images, because it was just unusable on Athlon64 3500+.
There are more reports related to FF's performance on SVG. (https://bugzilla.mozilla.org/show_bug.cgi?id=302909, ...)

Comment 10

[Martijn Wargers (dead)]

*** Bug 347189 has been marked as a duplicate of this bug. ***

Comment 11

[Martijn Wargers (dead)]

Thanks for the testcases, especially the second testcase is nice, because it enables you to measure performance.

I see a regression in performance between 2005-10-25 and 2005-11-01, this was
the time when cairo was switched on for svg on windows.
I get appr. 3300 times with a 2005-10-25 build.
I get appr. 1300 times with a 2005-11-01 build.
I get appr. 1600 times with current trunk build.

So this is a regression from enabling cairo for svg on windows.

Comment 12

[ced.dupont]

Attachment: Optimized version of SpeedTest.xml

I found a trick to optimize the rendering of the svg block.
The first version of SpeedTest.xml is using the css option Strike:black to bold the title text.
In the second version, I replace it with font-weigth:bolder.
The visual effect is not exactly the same but the performance is much better.
First version, object updated 908 times
Second version, object updated 1283 times
So it represent a speed gain of 40%.

Comment 13

[Helder "Lthere" Magalhães]

Ran attachments on latest Firefox 2 release and nightly Firefox 3 build. According to Firefox 3 improvements, IMHO this issue could be marked fixed.

As a side note, this bug report's title is too general - maybe marking this fixed would invite testers filing more specific performance issues, but this is just a suggestion...

Running attachment "html with embbeded svg" revealed a weird issue which requires further analysis (to find out if it's a new bug, a test case issue or an already reported issue).

Results and browser string versions follow.


Attachment "html with embbeded svg":
Firefox 2 - looks fine
Firefox 3 - clipped!


Attachment "Count how many times we can move a svg element in 1 second":
Firefox 2 - 666 times
Firefox 3 - 1034 times


Attachment "Optimized version of SpeedTest.xml":
Firefox 2 - 893 times
Firefox 3 - 1332 times


Versions:
Firefox 2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Firefox 3 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040305 Minefield/3.0pre

Comment 14

[Timmy Brolin]

I am happy to see that performance improvements are being done.
An increase from 893 to 1332 translations per second is a 50% improvement in performance.
However, that level of performance pales when compared to Opera or Internet Explorer with the Adobe plugin.

Performance figures on Opera 9.27: 34269 times

So even after the 50% performance increase of Firefox, Opera is still 2470%(!) faster than Firefox.
The automated performance test does not seem to work on Internet Explorer with the Adobe plugin for some reason. But judging from rendering speed when dragging a few hundred SVG objects around, the performance of Internet explorer is comparable to that of Opera.

My opinion is that this bug cannot be closed as the performance of firefox SVG rendering is still less than 4% of that of Opera and Internet Explorer.

Try the svg file I posted above (2005-12-09 09:17:59 PDT) for a real world example of how the low performance of Firefox makes interactive SVGs almost unuseable.

Comment 15

[Helder "Lthere" Magalhães]

(In reply to comment #13)
> Results and browser string versions follow.
> Firefox 3 - clipped!

I've tried to find the root cause and reach the following conclusions:
 * Setting parent "svg" element height to a fixed size works around the «issue» (say, 'height="500px"' or 'height="500px"');
 * Setting viewbox property seems to fix it too (say, 'viewBox="0 0 800 350"');
 * Setting height to a percentage causes no effect ('height="100%"');

I tried finding expected behavior for the default view port [1] (regarding embedded content) but wasn't able to clarify this behavior... Also, nothing related was found searching [2]. Should this be taken to a mailing list [3] thread and/or to a new issue?

Version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

[1] http://www.w3.org/TR/SVG/coords.html#ViewportSpace
[2] https://bugzilla.mozilla.org/query.cgi
[3] http://groups.google.com/group/mozilla.dev.tech.svg/

Comment 16

[Jonathan Watt [:jwatt]]

Helder, the clipping you're seeing is the result of fixing bug 294086. It is by design and required for conformance with SVG/CSS 2.1. The reason that testcase is being clipped is because the height defaults to 100%, but there is no fixed height for the CSS containing block. As a result, the height of the SVG falls back to 150px. You might wonder why setting the viewBox changes things. This is because SVG defines the viewBox as defining an intrinsic aspect ratio for the SVG. Therefore, the resolved width and the aspect ratio from the viewBox are used to set the height.

Comment 17

[Helder "Lthere" Magalhães]

(In reply to comment #13)
> Firefox 3 - clipped!

(In reply to comment #16)
> Helder, the clipping you're seeing is the result of fixing bug 294086.

Thanks for the clarification! ;-) This cleans up the noise associated with comment 13 (regarding the possible clipping issue). :-)

Comment 18

[Alfred Kayser]

The last cases are not valid cases of testing svg rendering (they only change an attribute and opera/safari and even FF itself don't redraw the rendering each time), so that is only testing javascript and such.

As for the first testcase there seems to be no detectable difference in rendering speed between FF3 and Safari. 

So, either close this bug or provide a real testcase showing real svg rendering issues.

Comment 19

[Timmy Brolin]

(In reply to comment #18)
> So, either close this bug or provide a real testcase showing real svg rendering
> issues.
The performance differences between FF, IE and Opera are so painfully obvious.
Just try something like this: http://www.brolinembedded.se/misc/erlandsson.svg
Press left mouse button and drag the tree around a bit. The performance is horrible.

Comment 20

[Alfred Kayser]

On my Lenovo Thinkpad T61 there is no visible difference between Opera9.5 and Firefox3.1a2pre (except that Opera draws a blue border when zoomed in).
Safari draws the diagram, but when trying to move or zoom, the page become white/empty. 
IE7 doesn't handle svg image at all.

So far it seems that my FF3.1a2pre doesn't perform worse than Opera, and at least much better than Safari or IE7. 

May be I need to test with a slower machine, or we need an even bigger svg file to reproduce...

Comment 21

[Timmy Brolin]

IE handles SVG if you install the Adobe plugin.

I do not have the same version of FF as you. Could be it.

Comment 22

[Alfred Kayser]

Timmy, which version of FF do you have?

Comment 23

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

svg performance on those is fine for me, at least on my laptop with low-end intel gfx enabled.  marking with a bit of optimism, jwatt please reopen if I have erred.

Comment 24

[Alfred Kayser]

Firefox 4.0b7/nightly does about 9000-12000 moves
Chrome does about 500.000 moves (it is cheating?)
Opera does about 109.000 moves.

So, Firefox is still way behind on this: setAttribute on a svg node.

And perceived performance of the testcase in comment #6 is still worse than compared to Opera and Chrome.

So, while it is much faster than before, it is still way behind others on this specific testcase, which covers a very generic function.

Comment 25

[Robert Longson [:longsonr]]

Because all the moves are in a loop it's possible to ignore all but the last one when you invalidate the original and new areas. This is why it's not a real world test. It's not measuring what the bug was originally opened for.

Chrome is doing this. bug 539356 is about doing this for Firefox.

Comment 26

[Helder "Lthere" Magalhães]

> So, Firefox is still way behind on this: setAttribute on a svg node.

Isn't bug 270255 tightly related?

Comment 27

[Jonathan Watt [:jwatt]]

The work in bug 734079 makes a big difference. For me the "Optimized version of SpeedTest.xml" testcase goes from ~22,000 sets to ~180,000 sets, so roughly an 8x speed up.

The pre- and post-change nightlies that I tested were:

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

Comment 28

[Robert Longson [:longsonr]]

Time to call this done. We've surpassed the performance of GDI Firefox 1.5 by a significant margin which is what this bug was originially about.