13 Jan 2006 cinamod   » (Master)

Inkscape and SVG filters

It seems as though SVG filters are an oft-requested feature that the Inkscape developers haven't gotten around to implementing quite yet.

In case any of them are reading this syndicated somewhere, I'd just like to offer them a small piece of the solution and some advice, which they're free to do with as they will. Librsvg has implemented the drawing-side code for filters. No doubt, it could use some cleaning up and restructuring (and we'd love contributions back), but the code is there, is freely available, and just works. You'll still need to write all of the code for creating and manipulating the filters, but at least the rendering part is already done.

From what I understand from their emails, they're blocking filters on Cairo/Xara integration, which I don't quite understand. The filters all operate on pixel data, not SVG maths. As such, they're independant of Cairo, Libart, or whatever one wants to draw with. The small-but-important exception is that one needs to be able to turn a specified region of the source graphic into a pixel buffer in order to use it with these filter functions (which Inkscape probably almost already has, since it uses libart to draw), and the ability to blit pixel data back onto the source graphic (which Inkscape necessarily has, since it supports the <image> tag). In librsvg, this has always been a pretty small shim, regardless of whether we were using Cairo or libart.

Also, they claim that Cairo is "slow". From librsvg's experience, it's anything but, at least compared to what we were using. Link Inkscape, we once used libart_lgpl. Cairo's image surface has been between 1.5x and 10x faster than using libart. My best guesses as to why are because it uses ARGB rather than RGBA pixel ordering and that libpixman's gradient-generating code is pretty good. Sure, it might not be able to (currently) draw 10 gazillion polygons per second like Xara claims to do, but does Inkscape really need that level of performance? I'd also like to see the code/tests Xara used in their performance comparison.

Anyway, we abstracted out our rendering into a 6-method interface that's implementable via Cairo or libart in ~1100 lines of C code. It's proven indispensable. Once you've chosen a good enough rendering abstraction, swapping in Cairo, Xara, or $flavour-of-the-week under the hood shouldn't be a problem down the road.

If SVG filters are your most requested feature, and it really is more than "just a one person job", please consider stealing liberally from us. GNOME needs more pretty icons and widget themes.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!