Am Montag, den 11.09.2017, 10:41 +0200 schrieb Julien Nicoulaud: > Hi all,
Hi Julien, Sorry for the late response. > Is it a known issue for Eye Of Gnome to be pathologically slow at > rendering large SVG images ? > (not that large actually, i'm attaching an example image that is > ~1000x1000) eog uses librsvg for rendering SVGs which in turn uses libcairo for the actual drawing calls. Zooming into your example profiling shows that it spends the most time applying gaussian blur filters, which is not unexpected considering the large number of blurred objects involved here. > When loading this image, my whole system (not only EoG) becomes > unresponsive for every action (loading the image, zooming, clicking > menus). I could observe this in up-to-date Fedora and Arch Linux (EoG > 3.24.1), in GNOME and Cinnamon. Yes, this could very well be as the blur filter maxes out one CPU core for ~15sec on my machine, but doesn't noticeably slow down the rest of the system. Depending on how fast your CPU is an how often eog needs to redraw (e.g. because of the overlay or another window obstructing it) this could cause a noticeable slow-down. > Web browsers (Firefox, Chromium) render this image instantly. So I > was wondering if I am missing something ? Do I need to enable > hardware acceleration somewhere, or maybe I am missing a lib for > optimized drawing of SVG ? Well, I think browsers are likely using their own SVG render implementations which most likely also have SIMD code paths in place for the filtering, which librsvg doesn't have. So yes, there appears to be room for some optimization in librsvg. But for that to be resolved I'd like to ask you to open a bug for librsvg in our Bugzilla so that the librsvg developer can have a look at this case. It could just as well be an edge case being triggered. Regards, Felix _______________________________________________ eog-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/eog-list
