GNOME Bugzilla – Bug 551736
librsvg very slow at rendering specular lighting filters
Last modified: 2017-12-13 17:33:22 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
Created attachment 118479 [details] Sample image causing the loop.
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')
-- 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.