After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 551736 - librsvg very slow at rendering specular lighting filters
librsvg very slow at rendering specular lighting filters
Status: RESOLVED OBSOLETE
Product: librsvg
Classification: Core
Component: general
2.22.x
Other All
: Normal major
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2008-09-10 22:01 UTC by David Paleino
Modified: 2017-12-13 17:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample image causing the loop. (25.60 KB, image/svg+xml)
2008-09-10 22:02 UTC, David Paleino
Details

Description David Paleino 2008-09-10 22:01:15 UTC
Please describe the problem:
Hello,
a Debian user reported a bug in gthumb, which indefinitely loops when loading
an unbound SVG image (attaching it). After talking with gthumb's authors, he pointed me to librsvg.
The current librsvg version I have is:

$ dpkg -l librsvg2-2 | grep ^ii
ii  librsvg2-2     2.22.2-2               SAX-based renderer [..]
$

This bug has been there since gthumb 2.6.2, which probably used a different version of librsvg.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?
Yes.

Other information:
Please refer to #228242 [0] for more information.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288242
Comment 1 David Paleino 2008-09-10 22:02:55 UTC
Created attachment 118479 [details]
Sample image causing the loop.
Comment 2 palfrey 2008-09-16 14:00:06 UTC
I can get this to render with rsvg-view (one of the test tools from librsvg) and that same version of librsvg2-2, but it is *incredibly* slow (even on my pretty damn fast machine). Admittedly, it's asking for some very heavy filters, but this still needs optimising further. My limited profiling (very adhoc, repeated stopping of gdb and eyeballing of the stacktrace) seems to indicate that the major time sink is the specular lighting filter and so I've re-titled this bug accordingly.

(Also, as this doesn't cause data loss, a crash or a memory leak, I've downgraded this bug to 'major' rather than 'critical')
Comment 3 GNOME Infrastructure Team 2017-12-13 17:33:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/librsvg/issues/22.