-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For rasterizing SVG images we've used librsvg for some time. Another contender which we didn't choose originally is Batik. There are several respects in which librsvg is unsatisfactory and Batik might be preferable.
With Sun finally in the process of releasing their Java implementation under GPL, we don't have to worry about being so ideologically 'pure' about Java-based solutions these days... So I went ahead and did a quick rendering benchmark with some images plucked off of Commons:
http://www.mediawiki.org/wiki/SVG_benchmarks
rsvg is beating the pants off Batik by a factor of 6; on my laptop the average image in the sample took *two seconds* to render, compared to a third of a second for rsvg.
Java is traditionally slow for command-line-type tasks, with VM startup and JIT overhead inflating times significantly. It's possible that we could get much better performance by starting up a single VM and sending multiple requests to it.
If we can get performance out of Batik that approaches or exceeds librsvg, it may be desirable to consider switching.
On the other hand if it's still slow as a dog, we can forget it and concentrate on other things.
Would anyone like to fiddle with this, put together a test daemon? (Or at least a test program that uses the library to render a bunch of images from a list, so we can benchmark.) It's probably not that difficult, and would be a fun way for some of the Java-heads in the room to get involved. ;)
If nobody hops in, it has to wait until I get around to it, and well... ;)
- -- brion vibber (brion @ pobox.com)
On 12/19/06, Brion Vibber brion@pobox.com wrote: [snip]
rsvg is beating the pants off Batik by a factor of 6; on my laptop the average image in the sample took *two seconds* to render, compared to a third of a second for rsvg.
Java is traditionally slow for command-line-type tasks, with VM startup and JIT overhead inflating times significantly. It's possible that we could get much better performance by starting up a single VM and sending multiple requests to it.
If we can get performance out of Batik that approaches or exceeds librsvg, it may be desirable to consider switching.
[snip]
Another engine to keep our eyes on is inkscape, which also can be used as a batch rasterizer. While it, like rsvg, lacks the completeness of Batik, it has a couple of qualities worth our attention:
1) Unlike rsvg it is actively developed and will one day be reasonably feature complete. (it will soon have filters for example) 2) Unlike both rsvg and batik it's also a full authorship environment.. in a perfect world we'd expect all renders to be consistent, but they are not.. so if we're going to be wrong it's better to be wrong in the same was as a tool people can actually use.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
Another engine to keep our eyes on is inkscape, which also can be used as a batch rasterizer. While it, like rsvg, lacks the completeness of Batik, it has a couple of qualities worth our attention:
- Unlike rsvg it is actively developed and will one day be reasonably
feature complete. (it will soon have filters for example)
Note that rsvg is actively developed, seeing several releases a year. The web page is grossly out of date, however.
- Unlike both rsvg and batik it's also a full authorship
environment.. in a perfect world we'd expect all renders to be consistent, but they are not.. so if we're going to be wrong it's better to be wrong in the same was as a tool people can actually use.
Mm, maybe.
Generally I'm leery about a GUI tool and all its dependencies; that has much of the same issues as librsvg.
- -- brion vibber (brion @ pobox.com)
On 19/12/06, Gregory Maxwell gmaxwell@gmail.com wrote:
Another engine to keep our eyes on is inkscape, which also can be used as a batch rasterizer. While it, like rsvg, lacks the completeness of Batik, it has a couple of qualities worth our attention:
- Unlike rsvg it is actively developed and will one day be reasonably
feature complete. (it will soon have filters for example) 2) Unlike both rsvg and batik it's also a full authorship environment.. in a perfect world we'd expect all renders to be consistent, but they are not.. so if we're going to be wrong it's better to be wrong in the same was as a tool people can actually use.
3) Rather a lot of the SVGs on Wikimedia are *created* using Inkscape, so the rendering will be precisely what the author saved.
- d.
On 12/19/06, David Gerard dgerard@gmail.com wrote:
- Rather a lot of the SVGs on Wikimedia are *created* using Inkscape,
so the rendering will be precisely what the author saved.
Except for differences in the font collections.. although we should make sure to have at least one consistent font installed everywhere and tell people on all platforms to use that font. (The obvious recommendation would be dejavu http://dejavu.sourceforge.net/wiki/index.php/Main_Page since it's complete, free, and included in most current Linux distros as the default font).
On the other hand if it's still slow as a dog, we can forget it and concentrate on other things.
I had a hell of a time with Batik when WikiTeX first supported it; in addition to the Java overhead, you have to have a framebuffer running on your headless server.
-- Peter Danenberg . wikisophia.org ..:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Danenberg wrote:
On the other hand if it's still slow as a dog, we can forget it and concentrate on other things.
I had a hell of a time with Batik when WikiTeX firstsupported it; in addition to the Java overhead, you have to have a framebuffer running on your headless server.
It seems reasonably happy with setting awt to headless mode.
- -- brion vibber (brion @ pobox.com)
Well brion,
I have never been able to get librsvg to work at all on 1.8.2, so Batik may be a solution.
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For rasterizing SVG images we've used librsvg for some time. Another contender which we didn't choose originally is Batik. There are several respects in which librsvg is unsatisfactory and Batik might be preferable.
With Sun finally in the process of releasing their Java implementation under GPL, we don't have to worry about being so ideologically 'pure' about Java-based solutions these days... So I went ahead and did a quick rendering benchmark with some images plucked off of Commons:
http://www.mediawiki.org/wiki/SVG_benchmarks
rsvg is beating the pants off Batik by a factor of 6; on my laptop the average image in the sample took *two seconds* to render, compared to a third of a second for rsvg.
Java is traditionally slow for command-line-type tasks, with VM startup and JIT overhead inflating times significantly. It's possible that we could get much better performance by starting up a single VM and sending multiple requests to it.
If we can get performance out of Batik that approaches or exceeds librsvg, it may be desirable to consider switching.
On the other hand if it's still slow as a dog, we can forget it and concentrate on other things.
Would anyone like to fiddle with this, put together a test daemon? (Or at least a test program that uses the library to render a bunch of images from a list, so we can benchmark.) It's probably not that difficult, and would be a fun way for some of the Java-heads in the room to get involved. ;)
If nobody hops in, it has to wait until I get around to it, and well... ;)
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFh328wRnhpk1wk44RAlllAKDPOb3MrS/yvLF1WZJlgNu53qv5rQCguxDj 3hMsb+2/+pv+B+VZzxLoSV8= =9u2X -----END PGP SIGNATURE----- _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 12/19/06, Brion Vibber brion@pobox.com wrote: [snip]
Would anyone like to fiddle with this, put together a test daemon? (Or at least a test program that uses the library to render a bunch of images from a list, so we can benchmark.) It's probably not that difficult, and would be a fun way for some of the Java-heads in the room to get involved. ;)
So I decided to do this, .. but I discovered that the batik-rasterizer.jar already supports running on a collection of svgs in a single run. It's much faster than running it once per image, but still much slower than rsvg.
My test collection is 10 'hard svgs' (average size of about 200k, all commons featured images) plus 10 'easy svgs' (color bar flags all around 1k or so).
Inkscape is 0.44.1 (fedora rpms) Rsvg is 2.16.1 (fedora rpms) batik is 1.6 on SUN Jre 1.5.0_09
System under test is a 1.5ghz pentium-m.
Test - Wallclock time * rsvg 800px - 14.2 seconds * Inkscape 800px - 18.277 seconds * Batik 800px - 38.7 * rsvg 250px - 7.9 seconds * Inkscape 250px - 8.5 seconds * Batik 250px - 25.5 seconds
Java vm for Batik is in client mode (server mode is quite a bit slower.. perhaps on a bigger test set? .. I'll try one later on an opteron box). Inkscape is called with --without-gui -w width, and both rsvg and inkscape are forked once per image.
wikitech-l@lists.wikimedia.org