-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Erik tossed this interesting tidbit my way:
http://codewideopen.blogspot.com/2008/09/inkscape-shell-patch.html
Inkscape can already be used on the command-line to do SVG to PNG conversions, but there's some folks working on patches to allow a single process to accept multiple requests over time. This may confer a performance advantage, avoiding startup costs, but I haven't seen any stats.
Currently we use the GNOME librsvg library for our SVG rasterizations; it's fairly fast and of course built for embedded rasterization, but it's traditionally been a bit behind on bug and feature implementation, so some files don't render correctly.
I think we're currently a few versions behind on librsvg, so probably an upgrade would help a lot, but we still toss around the idea of just shelling out to Inkscape.
Anybody interested in doing a sample run of known-bad-on-rsvg SVGs with the latest rsvg to compare against inkscape, and maybe some performance stats comparing rsvg, inkscape, and these experimental batch mode inkscapes? Should be fun! :D
(You'll find lots of examples of not-rendering-right files on our bugzilla -- search for SVG!)
- -- brion
Brion Vibber wrote:
(You'll find lots of examples of not-rendering-right files on our bugzilla -- search for SVG!)
See also http://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg_bug
2008/9/15 Nikola Smolenski smolensk@eunet.yu:
Brion Vibber wrote:
http://codewideopen.blogspot.com/2008/09/inkscape-shell-patch.html (You'll find lots of examples of not-rendering-right files on our bugzilla -- search for SVG!)
See also http://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg_bug
Interesting! See also my ad-hoc benchmarks at:
http://www.mediawiki.org/wiki/SVG_benchmarks
From those I disrecommended Inkscape on Unix systems - the rendering
is good, but rsvg is twice as fast and uses much less memory. (On Windows, the fact that Inkscape comes in a standalone package makes it much easier to set up and use, and mediawiki-l has many happy users of Inkscape for SVGs on Windows.)
But rsvg is a library and Inkscape is a full application, so that would *plausibly* explain the overhead (I don't know if it's actually the case).
Obviously those will need rerunning with the Inkscape shell if anyone has a spare moment :-)
What's the quality of in-browser SVG rendering on Firefox 3.0 and 3.1? Looking at it casually, FF 3 betas did good rendering but weren't very fast. OTOH, sending the hard work to the client when you know it's up to the task is reasonable these days. I believe ordinary HTML <img src="something.svg" height=nn width=nn> works fine. (Haven't tried Safari, Chrome or Opera.)
- d.
[cc: to mediawiki-l]
On 16.09.2008, 13:35 David wrote:
2008/9/15 Nikola Smolenski smolensk@eunet.yu:
Brion Vibber wrote:
http://codewideopen.blogspot.com/2008/09/inkscape-shell-patch.html (You'll find lots of examples of not-rendering-right files on our bugzilla -- search for SVG!)
See also http://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg_bug
Interesting! See also my ad-hoc benchmarks at:
http://www.mediawiki.org/wiki/SVG_benchmarks
From those I disrecommended Inkscape on Unix systems - the rendering is good, but rsvg is twice as fast and uses much less memory. (On Windows, the fact that Inkscape comes in a standalone package makes it much easier to set up and use, and mediawiki-l has many happy users of Inkscape for SVGs on Windows.)
But rsvg is a library and Inkscape is a full application, so that would *plausibly* explain the overhead (I don't know if it's actually the case).
Obviously those will need rerunning with the Inkscape shell if anyone has a spare moment :-)
What's the quality of in-browser SVG rendering on Firefox 3.0 and 3.1? Looking at it casually, FF 3 betas did good rendering but weren't very fast. OTOH, sending the hard work to the client when you know it's up to the task is reasonable these days. I believe ordinary HTML <img src="something.svg" height=nn width=nn> works fine. (Haven't tried Safari, Chrome or Opera.)
- d.
[cc: to mediawiki-l]
http://en.wikipedia.org/wiki/Image:Flag_of_Mexico.svg is 500kb, while most uses of it are 25px thumbnails. Something must be done about it. Also, there are people who still use IE5, Netscape or other kinds of nonsense who will be unable to see SVGs.
2008/9/16 Max Semenik maxsem.wiki@gmail.com:
On 16.09.2008, 13:35 David wrote:
What's the quality of in-browser SVG rendering on Firefox 3.0 and 3.1? Looking at it casually, FF 3 betas did good rendering but weren't very fast. OTOH, sending the hard work to the client when you know it's up to the task is reasonable these days. I believe ordinary HTML <img src="something.svg" height=nn width=nn> works fine. (Haven't tried Safari, Chrome or Opera.)
http://en.wikipedia.org/wiki/Image:Flag_of_Mexico.svg is 500kb, while most uses of it are 25px thumbnails. Something must be done about it.
Er, yeah, there is that ... I suppose it would be plausible to render and cache tiny versions. (At this point it starts sounding complicated.)
Also, there are people who still use IE5, Netscape or other kinds of nonsense who will be unable to see SVGs.
I was thinking in terms of sending SVGs directly only to browsers that can definitely handle it, not to everyone. I'm not sure there's a reasonable capability check - FF2 thinks it can do SVGs, but does a horrible job.
- d.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Max Semenik Sent: 16 September 2008 10:50 To: Wikimedia developers Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs Inkscape?
On 16.09.2008, 13:35 David wrote:
2008/9/15 Nikola Smolenski smolensk@eunet.yu:
Brion Vibber wrote:
http://codewideopen.blogspot.com/2008/09/inkscape-shell-patch.html (You'll find lots of examples of not-rendering-right files on our bugzilla -- search for SVG!)
See also
http://commons.wikimedia.org/wiki/Category:Pictures_showing_a_librsvg
_bug
Interesting! See also my ad-hoc benchmarks at:
http://www.mediawiki.org/wiki/SVG_benchmarksFrom those I disrecommended Inkscape on Unix systems - the
rendering
is good, but rsvg is twice as fast and uses much less memory. (On Windows, the fact that Inkscape comes in a standalone
package makes it
much easier to set up and use, and mediawiki-l has many
happy users of
Inkscape for SVGs on Windows.)
But rsvg is a library and Inkscape is a full application, so that would *plausibly* explain the overhead (I don't know if
it's actually
the case).
Obviously those will need rerunning with the Inkscape shell
if anyone
has a spare moment :-)
What's the quality of in-browser SVG rendering on Firefox
3.0 and 3.1?
Looking at it casually, FF 3 betas did good rendering but
weren't very
fast. OTOH, sending the hard work to the client when you
know it's up
to the task is reasonable these days. I believe ordinary HTML <img src="something.svg" height=nn width=nn> works fine. (Haven't tried Safari, Chrome or Opera.)
- d.
[cc: to mediawiki-l]
http://en.wikipedia.org/wiki/Image:Flag_of_Mexico.svg is 500kb, while most uses of it are 25px thumbnails. Something must be done about it. Also, there are people who still use IE5, Netscape or other kinds of nonsense who will be unable to see SVGs.
See no reason why svg isn't precompressed with gzip, and given a svgz extension. Seems to require Content-Encoding: gzip header for Chrome & FF3
But then renders Opera, Chrome & FF3.
Jared
On Tue, Sep 16, 2008 at 8:14 AM, Jared Williams jared.williams1@ntlworld.com wrote:
See no reason why svg isn't precompressed with gzip, and given a svgz extension.
It's still 188K gzipped. The 22x13px PNG used in [[Bethlehem]] is 300 bytes, close to 1000 times smaller. Some way to compress SVGs *lossily* is clearly needed here.
Aryeh Gregor wrote:
On Tue, Sep 16, 2008 at 8:14 AM, Jared Williams jared.williams1@ntlworld.com wrote:
See no reason why svg isn't precompressed with gzip, and given a svgz extension.
It's still 188K gzipped. The 22x13px PNG used in [[Bethlehem]] is 300 bytes, close to 1000 times smaller. Some way to compress SVGs *lossily* is clearly needed here.
Philosophically, it shouldn't be done. Someone might want to print a Wikipedia article on a building, and the 500K flag would then look just right.
Pragmatically, if you don't care about printing articles on buildings and are ready to lossily compress SVGs, there is no particular need to use SVG when PNG will do.
Otherwise, the idea of lossily compressing SVGs is very interesting, and I believe it could be done :)
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Nikola Smolenski Sent: 16 September 2008 15:35 To: Wikimedia developers Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs Inkscape?
Aryeh Gregor wrote:
On Tue, Sep 16, 2008 at 8:14 AM, Jared Williams jared.williams1@ntlworld.com wrote:
See no reason why svg isn't precompressed with gzip, and
given a svgz
extension.
It's still 188K gzipped. The 22x13px PNG used in
[[Bethlehem]] is 300
bytes, close to 1000 times smaller. Some way to compress SVGs *lossily* is clearly needed here.
Philosophically, it shouldn't be done. Someone might want to print a Wikipedia article on a building, and the 500K flag would then look just right.
Pragmatically, if you don't care about printing articles on buildings and are ready to lossily compress SVGs, there is no particular need to use SVG when PNG will do.
Otherwise, the idea of lossily compressing SVGs is very interesting, and I believe it could be done :)
Not sure. Obviously working out the most effiecient stylesheet for a given svg, removing repeated style attributes would be one area. But might effect the editability of the image. It could be like trying to edit a minified javascript file.
Producing a smaller SVG thumbnail of a SVG image would definitely be possible. Looking at Flag_of_Mexico, almost all the coordinates have several decimal places, so could reduce the accurancy of those in a smaller image without loosing anything.
Jared
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Jared Williams Sent: 16 September 2008 16:31 To: 'Wikimedia developers' Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs Inkscape?
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Nikola Smolenski Sent: 16 September 2008 15:35 To: Wikimedia developers Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs
Inkscape?
Aryeh Gregor wrote:
On Tue, Sep 16, 2008 at 8:14 AM, Jared Williams jared.williams1@ntlworld.com wrote:
See no reason why svg isn't precompressed with gzip, and
given a svgz
extension.
It's still 188K gzipped. The 22x13px PNG used in
[[Bethlehem]] is 300
bytes, close to 1000 times smaller. Some way to compress SVGs *lossily* is clearly needed here.
Philosophically, it shouldn't be done. Someone might want
to print a
Wikipedia article on a building, and the 500K flag would then look just right.
Pragmatically, if you don't care about printing articles on
buildings
and are ready to lossily compress SVGs, there is no
particular need to
use SVG when PNG will do.
Otherwise, the idea of lossily compressing SVGs is very
interesting,
and I believe it could be done :)
Not sure. Obviously working out the most effiecient stylesheet for a given svg, removing repeated style attributes would be one area. But might effect the editability of the image. It could be like trying to edit a minified javascript file.
Producing a smaller SVG thumbnail of a SVG image would definitely be possible. Looking at Flag_of_Mexico, almost all the coordinates have several decimal places, so could reduce the accurancy of those in a smaller image without loosing anything.
Jared
Actually seems a SVGCrush is in progress..
https://code.launchpad.net/~ted-gould/+junk/svgcrush-delivered
Jared
2008/9/16 Jared Williams jared.williams1@ntlworld.com:
Producing a smaller SVG thumbnail of a SVG image would definitely be possible. Looking at Flag_of_Mexico, almost all the coordinates have several decimal places, so could reduce the accurancy of those in a smaller image without loosing anything.
Opting for producing a cached PNG thumbnail in the example given (tiny flag images) as is done at present is likely suitable when the page is explicitly asking for a tiny thumbnail. Send the full SVG for the printed stylesheet, maybe.
(this is all highly theoretical and going nowhere without running code of course)
- d.
On Tuesday 16 September 2008 17:30:56 Jared Williams wrote:
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Nikola Smolenski Sent: 16 September 2008 15:35 To: Wikimedia developers Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs Inkscape? Philosophically, it shouldn't be done. Someone might want to print a Wikipedia article on a building, and the 500K flag would then look just right.
Pragmatically, if you don't care about printing articles on buildings and are ready to lossily compress SVGs, there is no particular need to use SVG when PNG will do.
Otherwise, the idea of lossily compressing SVGs is very interesting, and I believe it could be done :)
Not sure. Obviously working out the most effiecient stylesheet for a given svg, removing repeated style attributes would be one area. But might effect the editability of the image. It could be like trying to edit a minified javascript file.
If that's what you had in mind, that's possible, but the gains would probably not be very big. Note also that we don't minify javascript files, compress HTML or anything similar.
Producing a smaller SVG thumbnail of a SVG image would definitely be possible. Looking at Flag_of_Mexico, almost all the coordinates have several decimal places, so could reduce the accurancy of those in a smaller image without loosing anything.
Just did it. The file got almost twice smaller (more than twice when I removed unnecessary spaces), the gzipped file got almost thrice smaller (than the gzipped original), and the differences are barely noticeable. I'm still not sure if we should do it.
On Wed, Sep 17, 2008 at 2:51 AM, Nikola Smolenski smolensk@eunet.yu wrote:
Just did it. The file got almost twice smaller (more than twice when I removed unnecessary spaces), the gzipped file got almost thrice smaller (than the gzipped original), and the differences are barely noticeable. I'm still not sure if we should do it.
The obvious next step would be to get Mexico to make their flag less complicated.
On Tue, Sep 16, 2008 at 7:42 PM, Stephen Bain stephen.bain@gmail.com wrote:
The obvious next step would be to get Mexico to make their flag less complicated.
Yes, but that can still only get you so far. The SVG version of Libya's flag on Wikimedia is 286 bytes, but I can make an equally scalable GIF that's just 35 bytes. :P
On Tue, Sep 16, 2008 at 7:55 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Tue, Sep 16, 2008 at 7:42 PM, Stephen Bain stephen.bain@gmail.com wrote:
The obvious next step would be to get Mexico to make their flag less complicated.
Yes, but that can still only get you so far. The SVG version of Libya's flag on Wikimedia is 286 bytes, but I can make an equally scalable GIF that's just 35 bytes. :P
No you can't.
The GIF is only 'equally scalable' if you make certain (bad) assumptions about how it should be scaled which may be valid for that image but which would be completely wrong for most others.
Regardless: It's an utterly silly discussion: Except for users on unusually slow network connections located fairly close to Wikimedia clusters (and I mean substantially sub-dialup) load times will be the same* for all objects under ~4kbytes because they are latency bound and because of how TCP initial window sizing works. Likewise, on disk most file systems do not do sub-blocksize allocations.
*http://www.nedworks.org/~mark/tmp/minresponse-realworld2-rtt.png
On Tue, Sep 16, 2008 at 8:17 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Tue, Sep 16, 2008 at 7:55 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Yes, but that can still only get you so far. The SVG version of Libya's flag on Wikimedia is 286 bytes, but I can make an equally scalable GIF that's just 35 bytes. :P
No you can't.
The GIF is only 'equally scalable' if you make certain (bad) assumptions about how it should be scaled which may be valid for that image but which would be completely wrong for most others.
Maybe you were missing my point? The flag of Libya is solid green, so a one-pixel GIF is tiny and scales perfectly. My comment was about as serious as the one it was responding to, i.e., it wasn't.
The point about nothing mattering if it's under 4 KB is interesting, though, and worth keeping in mind for micro-optimizations.
On Tue, Sep 16, 2008 at 8:23 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Maybe you were missing my point? The flag of Libya is solid green, so a one-pixel GIF is tiny and scales perfectly. My comment was about as serious as the one it was responding to, i.e., it wasn't.
Libia has a 1:1 aspect ratio flag?!
But really, no it doesn't 'scale perfectly': Any image that when properly downsampled to 1px produces the correct green color is a 'correct' upsampling of a 1px by 1px green image. That the upsamplers you tend to use are so unimaginative that they produce solid fields of green when given a single green pixel still does not make the 1px single color as scalable as a SVG.
The point about nothing mattering if it's under 4 KB is interesting, though, and worth keeping in mind for micro-optimizations.
Right, that was really why I bothered posting.
Sending SVGs to browsers in HTML code is easiest way of crushing those browsers ;)
I have FF 2.0.0.16 on Gentoo Linux (P4 1,8GHz mobile, 1GB RAM) and opening this image is very painful:
http://upload.wikimedia.org/wikipedia/commons/7/78/India_roadway_map.svg
How about your's browsers? How about one page with 5 embedded such images? How about 1x1px image with 1M nodes inside?
AJF/WarX
On Wed, Sep 17, 2008 at 11:21 PM, Artur Fijałkowski wiki.warx@gmail.com wrote:
Sending SVGs to browsers in HTML code is easiest way of crushing those browsers ;)
I have FF 2.0.0.16 on Gentoo Linux (P4 1,8GHz mobile, 1GB RAM) and opening this image is very painful:
Chrome handles it fine on Windows (Dual core 2.4GHz, 2GB of RAM or so). 2-3 seconds to load completely.
2008/9/17 Andrew Garrett andrew@epstone.net:
Chrome handles it fine on Windows (Dual core 2.4GHz, 2GB of RAM or so). 2-3 seconds to load completely.
Firefox 3 on my computer takes maybe five seconds, and I've heard there are at least some SVG speed improvements in 3.1:
http://weblogs.mozillazine.org/roc/archives/2008/07/svg_filter_perf.html
Regardless, even a two-second render time is probably unacceptable for inclusion into a page, and times even five images it's certainly not tolerable. I certainly wouldn't call it "fine" to wait an extra two seconds for a page to load. All client SVG implementations need to become considerably faster before it's likely to be a good idea to include complicated SVGs in web pages. Better hardware might even be needed, given the costs of rasterization, but I don't know enough to say whether that's true or not.
20 seconds (gasp!) on Camino. Ugh.
Soxred
On Sep 17, 2008, at 10:00 AM [Sep 17, 2008 ], Aryeh Gregor wrote:
2008/9/17 Andrew Garrett andrew@epstone.net:
Chrome handles it fine on Windows (Dual core 2.4GHz, 2GB of RAM or so). 2-3 seconds to load completely.
Firefox 3 on my computer takes maybe five seconds, and I've heard there are at least some SVG speed improvements in 3.1:
http://weblogs.mozillazine.org/roc/archives/2008/07/ svg_filter_perf.html
Regardless, even a two-second render time is probably unacceptable for inclusion into a page, and times even five images it's certainly not tolerable. I certainly wouldn't call it "fine" to wait an extra two seconds for a page to load. All client SVG implementations need to become considerably faster before it's likely to be a good idea to include complicated SVGs in web pages. Better hardware might even be needed, given the costs of rasterization, but I don't know enough to say whether that's true or not.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Sep 16, 2008 at 10:35 AM, Nikola Smolenski smolensk@eunet.yu wrote:
Philosophically, it shouldn't be done. Someone might want to print a Wikipedia article on a building, and the 500K flag would then look just right.
When most people have gigabit downlinks from the Internet, I think this will be an entirely feasible position. :) Until then, we have to compromise.
Pragmatically, if you don't care about printing articles on buildings and are ready to lossily compress SVGs, there is no particular need to use SVG when PNG will do.
Otherwise, the idea of lossily compressing SVGs is very interesting, and I believe it could be done :)
I think the best way to lossily compress SVGs is, yeah, just to convert to PNG. I'd like to see anyone get the level of detail of that Mexican flag in an SVG displayed at 22x13px . . . that's 300 bytes in size. When you're talking about very low resolutions, even very crude vector images are almost certainly going to describe much more detail than is useful.
On Tue, Sep 16, 2008 at 11:55 AM, David Gerard dgerard@gmail.com wrote:
Opting for producing a cached PNG thumbnail in the example given (tiny flag images) as is done at present is likely suitable when the page is explicitly asking for a tiny thumbnail. Send the full SVG for the printed stylesheet, maybe.
I don't think there would be any way to send different images based on stylesheets.
Anyway, this is kind of off-topic, as far as rsvg vs. Inkspace goes.
David Gerard wrote:
What's the quality of in-browser SVG rendering on Firefox 3.0 and 3.1? Looking at it casually, FF 3 betas did good rendering but weren't very fast. OTOH, sending the hard work to the client when you know it's up to the task is reasonable these days. I believe ordinary HTML <img src="something.svg" height=nn width=nn> works fine. (Haven't tried Safari, Chrome or Opera.)
Ijust checked and it still doesn't. Using a <img tag fails. You need an <iframe, <object or <embed to show it. However, old Safari versions seem to crash with <object http://www.alleged.org.uk/pdc/2002/svg-object.html
Also, I found that placing many svgs on a page allowed to perform a denial of service (firefox 2 freezed while trying to do the expensive operation of rendering), which is an important point to take into account in a wiki.
2008/9/16 Platonides Platonides@gmail.com:
Also, I found that placing many svgs on a page allowed to perform a denial of service (firefox 2 freezed while trying to do the expensive operation of rendering), which is an important point to take into account in a wiki.
FF2's SVG rendering is horrible. You'd need one of the browsers aspiring to HTML5, and to reliably detect such. It would probably not be suitable to roll out this year!
Has anyone experimented with direct in-browser SVG rendering in Mediawiki?
- d.
On Mon, Sep 15, 2008 at 2:34 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Erik tossed this interesting tidbit my way:
http://codewideopen.blogspot.com/2008/09/inkscape-shell-patch.html
Inkscape can already be used on the command-line to do SVG to PNG conversions, but there's some folks working on patches to allow a single process to accept multiple requests over time. This may confer a performance advantage, avoiding startup costs, but I haven't seen any stats.
[snip]
http://www.nabble.com/Fun-project:-write-and-profile-a-Batik-server-td794205...
For a while I was automatically detecting SVGs from the site that broke inkscape (usually causing it to gobble oodles of ram) and feeding them to inkscape developers. I have no clue if those issues were fixed. Regardless of the batch processing patches, inkscape's increased completeness seemed to justify the slight loss of performance, but the stability problems were deal breakers.
wikitech-l@lists.wikimedia.org