Re: EOG painfully slow with large SVG images

[Felix Riemann <friemann gnome org>]

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