SVG benchmarks

Background
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.

Reasons in favor of librsvg:
 * fast
 * totally free/libre

Reasons against librsvg:
 * Lots of GNOME-ish dependencies, which makes tracking updates difficult
 * We have to maintain a security patch to disable the loading of external URL resources, since librsvg maintainers weren't interested in it
 * Lots of rendering bugs (but it's improved over time)
 * Unclear fonts/text rendering situation

Reasons in favor of Batik:
 * more mature
 * higher quality rendering
 * built-in security mode

Reasons against Batik:
 * slow!
 * doesn't (or at least didn't) run on free/libre Java (GCJ etc)

Benchmark
I did a quick test of SVG rendering, with 50 images pulled off Commons.

Rendering files from svg to rsvg .................................................. 18.07 seconds; 361.46ms per image

Rendering files from svg to batik ................................................. 108.44 seconds; 2168.84ms per image

Test run on a MacBook, 2 GHz Intel Core 2 Duo, in Ubuntu running under Parallels (using one virtual processor).

rsvg is 2.16.0 as apt-get'd via Ubuntu

batik is 1.6, running on Sun's J2SE 6 runtime.

Batik is probably slowed down by having to start up the VM and JIT on every call. It likely can be sped up by using a daemon process and handing off render requests to that. I may play with that a bit later if no one else wants to take it on.

Batik also refused to render one file that rsvg did render.

It may also be worth looking at Batik current dev code; is it faster/better/etc? --Brion VIBBER 00:01, 19 December 2006 (UTC)

To avoid JDK startup time you can use nailgun. ivar 05:10, 14 December 2007 (UTC)

Additional notes
Batik command-line renderer appears to scale image height to be proportional with the given width. This could produce width/height inconsistencies between specified heights from MW and results.

I'm pretty sure Batik has a mode for increased safety (rejecting external links), which we have to maintain as a patch hack for librsvg. Not having to maintain a patch is attractive.

We frequently get requests about font support. It'd be nice to know how to answer such questions.

rsvg's resource usage can be limited with ulimit etc easily; what about a batik daemon? How to stop giiaaannttttt files from eating up RAM without taking down the server?
 * You'd have to look at jvm args... -- chris