431984 - svg image makes firefox sluggish and unresponsive

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Matěj Cepl]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5

(originally filed as Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=444860)

Loading the image below makes my copy of Firefox (f9-preview) very slow and
unresponsive). Moreover, the image is not displayed correctly but it doesn't fits into the firefox (or epiphany/xulrunner-based) window.

The same SVG file works reasonably fast with gthumb (approx. 5 sec delay).
(further comments in the Fedora bug) or when used as Gnome background. There might be actually some problem with the SVG image itself -- it behaves the same as with firefox also with epiphany/webkit-based.

Reproducible: Always

Steps to Reproduce:
1.open the file with firefox or epiphany (both xulrunner-based and webkit-based)
2.
3.
Actual Results:  
a) it takes a LOT of time to render (a minute or so)
b) the image is rendered MUCH bigger than the browser windows is

Expected Results:  
renders reasonably fast and fits into the browser window

Comment 1

[Robert Longson [:longsonr]]

This would benefit enormously from bug 418201. (Restricting
filter processing to the dirty rect would greatly speed up the really large objects that are mostly offscreen.)

Comment 2

[techtonik]

I can confirm the same happens on Windows 2000

Comment 3

[Robert Longson [:longsonr]]

I get strange rendering when I scroll this. I see discontinuities between the previously visible and newly visible areas.

Comment 4

[Robert Longson [:longsonr]]

Forgot to say that those discontinuities are with the latest trunk build

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, I see that too. Must be a regression :-(. I'll work on it. First I need to minimize the testcase...

There is nothing to say that the SVG image should be scaled to fit in the window. Maybe it should, but that's really a feature request and should be filed as a separate bug.

As for what this bug summary is about, I guess we're being compared to librsvg? Looking at the librsvg Gaussian blur code, I'd be stunned if it's nearly as fast as our trunk code (let alone faster):
http://svn.gnome.org/viewvc/librsvg/trunk/rsvg-filter.c?view=markup
The Fedora bug doesn't mention gthumb so I don't know what kind of comparison was made. If you render the image at the same size in both Gecko and librsvg Gecko should be at least as fast.

Note, though, we don't cache the rendered image in a pixmap but both gthumb and the GNOME desktop presumably do, so Firefox will indeed be sluggish and unresponsive while this image is visible. I'm reluctant to start caching SVG renderings in pixmaps though, since it gets complicated fast when you consider that for a large class of SVG images that's just a waste of memory, and we (unlike librsvg) have to handle dynamic changes to the container and also the SVG content.

(Does Webkit even implement the filter blurs? Last I checked Safari didn't ship with filters. Perhaps Alp or someone else implemented filters for Webkit/GTK.)

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Filed bug 445410 on that scrolling regression.

Comment 7

[Robert Longson [:longsonr]]

Firefox is correct in not scaling it to fit the window. It would need an outer svg width and height of 100% for that to happen.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 445410 is mostly fixed and that seems to have fixed the problems mentioned in comment #3.

Comment 9

[Robert Longson [:longsonr]]

Marking as WFM as item a) is fixed and item b) is invalid i.e. the image should be bigger than the browser window.