Closed Bug 609361 Opened 14 years ago Closed 9 years ago

SVG takes ages to render. Is ok in other browsers, like Opera or Safari.

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: scalablev, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: perf, Whiteboard: [in-the-wild] [external-report] [painting-perf] [cairo path stuff])

Attachments

(1 file)

testcase
(deleted), image/svg+xml
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 My Firefox 3.6 struggles real hard to draw http://kart.nois.no/pub/oye/ie9/mapfile.svg The whole browser becomes unresponsive for a while. Opera has no problems with it. Why is this? Reproducible: Always Steps to Reproduce: 1.Visit the url. 2.Wait. 3.And wait. Actual Results: Content shows. Eventually. Browser is sluggish. Expected Results: Should show immediately.
Boris, What does the profiler say?
Nothing. In 3.6, I see a flash of black for about 500ms, then the map. On trunk, I just see the map pretty much immediately after hitting enter on the url bar. So nothing to profile.... Robert, are you seeing the problem? If so, are you on Windows? Might be OS-specific; I'm on Mac.
I'm seeing it on Windows. Seems to spend time in drawing the polylines I think. Trunk does seem faster than 3.6 but it's still 10 seconds or so.
Sounds pretty likely to be a cairo-windows specific issue then, no? Which answers the question from comment 0: Opera doesn't use cairo. ;) Robert, want to attach a standalone version of this SVG to the bug, for posterity?
Status: UNCONFIRMED → NEW
Component: SVG → Graphics
Ever confirmed: true
QA Contact: general → thebes
Attached image testcase (deleted) —
Trunk Windows may be several seconds, but 3.6 Windows is at least minutes, in fact not sure it's ever going to display anything.
On my Linux box (with Compiz enabled, if that matters): - My Firefox 3.6 nightly has a CPU spike for about 10 seconds when I load the page, *and* each time I focus the page. The CPU spike has 90% usage by Xorg, though, and maybe 30% firefox-bin. (multi-core system, so they don't add up to 100) - My mozilla-central nightly has pretty much the exact same behavior, except that CPU usages are reversed (30% Xorg, 90% Firefox), and the spike doesn't seem to last quite as long.
Yeah, on focus/blur we invalidate (and hence repaint) the entire window. Known silliness. So in your case it just takes 10 seconds to paint the SVG.... I wonder what cairo is doing right on Mac here!
Cairo on Mac is much less likely to be comparable to Cairo on Windows/Linux; on Mac we rarely use pixman, whereas on Linux/Windows we frequently/always do.
Oh, because CG has its own path stuff and whatnot? I can believe this being a pixman bug....
blocking2.0: --- → ?
(In reply to comment #11) > What are the chances of getting a quick fix for this? I currently have to > advice customers to NOT use Firefox. Better if you reduce the testcase so that it has the fewest possible elements but is still slow.
I think we need _some_ way of tracking bugs like this: ones that are not fx4 blockers but should be priorities for the next release...
Whiteboard: [painting-perf]
See bug 616604 comment 4 for the QA work that needs to happen here.
Keywords: qawanted, testcase-wanted
Blocks: 623923
Keywords: perf
Whiteboard: [painting-perf] → [painting-perf][cairo path stuff]
This is still an issue; it will likely be better when we can transition SVG to the new 2D API. For that reason, I'm going to move this to SVG. It can serve as a testcase.
Component: Graphics → SVG
QA Contact: thebes → general
Depends on: 703159
The original testcase in this bug now displays in less than a second for me. Same speed as Opera. suberu if you have issues with some other testcase then please raise another bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
(In reply to Robert Longson from comment #27) > The original testcase in this bug now displays in less than a second for me. > Same speed as Opera. I can not confirm that. Loading the Testcase (no Matter if HWA on/off) still renders slow compared to MSIE 10 and Opera 12.14. Firstly it renders a black Rectangle (5-6s) and then the Map Content (another 2-3s). In that Process the CPU is pegged 50-70% and Chrome UI is blocked. This is also the Case when switching Tabs/opening Chrome UI elements like the Firefox Button and its Menus. SPS against Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130330 Firefox/22.0 ID:20130330030828 CSet: 8693d1d4c86d: http://people.mozilla.com/~bgirard/cleopatra/#report=037075c456fe0d2cf5c9c2311cdb98ab51196e1d with HWA on in a newly created Profile.
Flags: needinfo?(longsonr)
Renders in the same time for me as Opera, about 1 second and that's without HWA.
Flags: needinfo?(longsonr)
Firefox 20.0, Kubuntu 12.04 The referenced SVG takes around 10 seconds to load, and it causes immense lag also when switching to and from that tab. Btw, this very same issue causes many chart-drawing libraries useless in firefox, simply because they use SVG. "RESOLVED WORKSFORME" is utmost ****.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
Darren and Ondrej: you're reading too much into the significance of "WORKSFORME". (It just means "I can't reproduce anymore; maybe it's fixed?", and it's definitely not absolute / irreversible if it turns out that other people can still reproduce) Regarding "Firefox 20.0, Kubuntu 12.04" -- note that we resolve bugs when they're fixed in trunk (currently at version 22), so it's not out of the ordinary that a bug would be resolved and yet still affect Firefox 20. (RE "utmost ****" and "slow and painful death" -- let's please keep bugzilla comments civil and on-topic. Pessimistic editorializing comments aren't helpful, and this isn't the place for them. Thanks.) Getting back to this bug -- in this case, I can still reproduce the bug on Firefox Nightly on my Lenovo W530 laptop, running Ubuntu 12.10. Firefox takes 4-5 seconds to render the attached testcase (and gets very laggy), whereas Opera loads it in less than a second, and Chrome loads it in slightly more than a second. Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20130401 Firefox/22.0 --> Reopening. [er -- looks like Robert beat me to reopening it, actually]
Note that in Firefox 3.6 which was what the original person who raised this was using, it used to take over a minute so somewhere in the 1-10 seconds range is a huge improvement over that.
We're actually spending a lot of the time under nsSVGFilterFrame::PaintFilteredFrame.
Depends on: 869496
Mozilla/5.0 (Windows NT 6.0; rv:25.0) Gecko/20130722 Firefox/25.0 Tested on latest Nightly 25.0a1 (buildID: 20130722030226). The original testcase from comment 5 does load in the same time (5-6s) as in Chrome or Opera (even faster) but every time I focus another tab there is a delay for about 3 seconds. Tested testcases from comment 25 on the same build and I can definitely see that in Firefox there is a glitch every time the image is dragged or zoomed in/out. It does not move smoothly. This behavior does not occur in Chrome or Opera. Dropping qawanted and testcase-wanted since there are a lot of examples here showing the issue. If there is any way QA can help here further on please add the qawanted keyword back.
Keywords: qawanted, testcase-wanted
Whiteboard: [painting-perf][cairo path stuff] → [in-the-wild] [external-report] [painting-perf] [cairo path stuff]
This doesn't seem to be caused by slow filters (any more?), so I'm removing the dependency on bug 869496.
No longer depends on: 869496
Moz2D conversion FTW! The attached testcase has hugely improved between 2014-09-30-03-02-02-mozilla-central and 2014-10-01-03-02-05-mozilla-central, or more precisely between these two builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1412096122/ http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1412096960/ https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3b427c2ee147&tochange=0ade54570f25 Of those those changes this improvement would have been caused by cd87b4cb26c1, "Bug 1074294, part 2 - Convert nsSVGPathGeometryFrame::Render() to render directly using the Moz2D DrawTarget". On my Macbook Pro the page load time goes from about 15s to 1-2s. For comparison this beats the pants off current Chrome Canary, where on the same machine the page appears to load blank in about 5s, but then takes about a further 20s before it actually renders.
Depends on: 1074294
(In reply to Jonathan Watt [:jwatt] from comment #39) > Of those those changes this improvement would have been caused by > cd87b4cb26c1, "Bug 1074294, part 2 - Convert > nsSVGPathGeometryFrame::Render() to render directly using the Moz2D > DrawTarget". The reason that this change caused such a dramatic improvement is because, whereas we used to do dashing for paths with a dash array with zero length gap(s), this commit changed us to detect that and optimize stroking without dashing. In terms of code change, we used to call nsSVGUtils::SetupCairoStrokeGeometry which called GetStrokeDashData which only returns a bool to optimize for zero length dash (as opposed to zero length gaps). We now call SVGContentUtils::GetStrokeOptions which calls its version of GetStrokeDashData which returns a tri-state flag instead of a bool so that the caller can differentiate between all dash (continuous), all gap (no stroke), and normal dashing. The reason http://kart.nois.no/pub/oye/ie9/mapfile.svg is so affected by this is because it styles a lot of its paths using |stroke-dasharray:1,0;| which is equivalent to not having dashing.
Is there something left to be done here?
I don't think so.
Status: NEW → RESOLVED
Closed: 12 years ago → 9 years ago
Resolution: --- → FIXED
Hey all, sorry for posting on the old thread. It's 2018 and SVG rendering is still notably slower in Firefox Quantum than other Browsers. I have an SVG animation that goes about 20-30 fps in Chrome, but about 0.1 - 1 fps on Firefox. It'd be awesome if the team could spend some time improving SVG.
Please file new bugs about specific slow SVG testcases you can find. It's much easier to improve performance when we have an actual page to test with.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: