GNOME Bugzilla – Bug 108435
SVG scaling support
Last modified: 2010-04-18 12:38:42 UTC
It'd be really great to be able to preview svg images with the eog. Right now you can see them as icons in nautilus but there is no way to actually view them in a program.
EOG can now view SVG files, but they are not scaled properly
Notes: Changed to GNOMEVER2.7. Added bugsquad keyword
Since SVG files are (in theory) infinitely scalable, to properly zoom in and out, EOG needs to recalculate the raster from the original SVG every time it is zoomed in or out or fullscreen. I would like to use EOG and a text editor to do SVG work. Not Possible unless real scaling is allowed.
moving to gnome 2.13
*** Bug 335576 has been marked as a duplicate of this bug. ***
Created attachment 66559 [details] [review] Re-render scalable images when zooming This patch will re-render scalable images when zooming. If the pixbuf loader says the image is scalable, the image data is saved inside the EogImage. When the user zooms in, if the image is scalable it will be re-rendered from the source data. This zoomed pixmap is saved in EogScrollView along with the original-size pixmap.
Created attachment 66562 [details] [review] Simpler version of the previous patch A much simpler version of the patch which has the added benefit of working correctly with full-screen mode. =P
Maybe I'm mistaken, but I think these patches bear the possibility to use quite a lot of memory especially when zooming in. The problem is that the re-rendering increases the in-memory pixel data used by the respective GdkPixbuf. An image at 2048x1536 uses about 12MB memory (using an RGBA32 visual because of transparency). When I zoom this in to 2000% it uses 240MB memory only for its pixel data. I think a better approach would be to take advantage of the fact that the image displaying component is a GtkDrawingArea which can be drawn to using cairo/librsvg. I'm not sure how this would behave in terms of memory usage.
I didn't consider the memory implications - you're right, Felix. Unfortunately, there doesn't seem to be any way to load a portion of an image without going around GDK and using librsvg directly. (Actually, a quick glance at the API docs makes me think librsvg doesn't support what we need, either.)
*** Bug 348175 has been marked as a duplicate of this bug. ***
*** Bug 364219 has been marked as a duplicate of this bug. ***
*** Bug 395280 has been marked as a duplicate of this bug. ***
*** Bug 532730 has been marked as a duplicate of this bug. ***
Is there any news on this issue? This has been nearly 2 years without further notice, so i just wanted to check if there are still plans to change the behaviour of eog. Thanks.
Years Later, eog still renders SVG files blurry on rescale. This is a vector graphics format so this is unnecessary. Can anyone recommend another viewer for svg files?
Inkview is very minimal, but renders SVGs very well. It's part of Inkscape.
Created attachment 156658 [details] [review] Attempt to render SVG with librsvg/cairo. Apparently slower then before.
Nice. Seems to work well so far. Haven't looked at the code yet, though. You might get a little bit faster by drawing the anti-aliased version directly, skipping the unfiltered version. Still librsvg doesn't seem to be the fastest, gradients seem to really slow it down.
(In reply to comment #18) > You might get a little bit faster by drawing the anti-aliased version directly, > skipping the unfiltered version. Yes, I tried it at first but it was negligible. The cost of svg rendering is very expensive. > Still librsvg doesn't seem to be the fastest, gradients seem to really slow it > down. I don't investigate about gradients yet, but found an issue for rendering. I filed a bug with a patch. The patch makes EOG significant faster. Please see bug #613672.
(In reply to comment #19) > (In reply to comment #18) > > > You might get a little bit faster by drawing the anti-aliased version directly, > > skipping the unfiltered version. > > Yes, I tried it at first but it was negligible. The cost of svg rendering is > very expensive. Hmm, I guess you're right. The experience feels better to me with showing the unfiltered version first as you see the UI react much quicker. > > > Still librsvg doesn't seem to be the fastest, gradients seem to really slow it > > down. > > I don't investigate about gradients yet, but found an issue for rendering. I > filed a bug with a patch. The patch makes EOG significant faster. Please see > bug #613672. Yes, helps a lot. I am going to review the patch for one of the first GNOME 2.32/3.0 development releases.
There we go. Thanks for the patch. commit 21caf5f03041e236157e967bf2c07832b5ba551b Author: Hiroyuki Ikezoe <> Date: Sun Apr 18 14:12:17 2010 +0200 Render SVGs using librsvg when filtering is enabled Redraws scaled SVGs correctly instead of just showing a scaled and filtered pixbuf. Note that depending on the filters used by the image rendering can be quite slow at large zoom factors. Fixes bug 108435. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.