Large improvements in filtering framework

I've been rather busy lately, and it's been cutting into time, I can spend developing Inkscape. Nevertheless, I've now committed a big filtering framework update. The filtering code can now access the bounding box as defined in SVG standard, not only the visual bounding box, that's used in many parts of display code. Also, the filtering code can now handle many more different situations involving rotated and/or skewed objects. This update has been needed for some time already, but I thought it might be too big to fit in this summer.

The most visible problem this fixes is a crash when trying to use blending modes on a rotated or skewed object. It transformed the object to a coordinate system, where the object's x- and y-axis were paraller to bitmap axis. Then it tried to blend that with the background image, that was still in display coordinates. The blending code then tried to fit these in same buffer, which became really huge and couldn't be reserved.

This also fixes several less visible bugs. If an object was rotated/skewed and the resolution for filter was specified, the specified resolution was discarded and automatic resolution used instead. Filter area calculations are more correct, because they can be made in correct coordinate system.

This also opens new parts, that should be improved. The filters, for which it makes a difference, what direction the object's axis point, should be tagged as such. Cutting the filter result to filter effects area should be implemented. A better sampling than nearest neighbour should be implemented for pixel block transformations. Probably several others too.

This modification isn't all good, though. In some cases with rotation or skewing, the image quality is visibly detoriated. Also there's a rather interesting effect with low-resolution filters. In the following images, first has a slight blur applied with 16x16 resolution. Second is same image, but with a slight rotation applied. This is caused by the fact, that for scaling there exists a bicubic scaler, but for more complex transformations there is only nearest neighbour filtering available. Actually, this behaviour doesn't even violate SVG standard, but it definitely is rather unintuitive. (also, if you look closely, you can notice an off-by-one bug with the resolution)

Assembly 2007

Once again, the Finnish demoparty Assembly has ended. Well, actually it ended already on Sunday, but anyhow.

It was really great to meet all those friends who were there, watch the demos and other compos, check out the booths etc. This year I had again created a intro to be shown at Assembly. Well, it was shown. The entries in 4k compo were of really good quality, and my style is obviously a bit odd, so it ended up on 10th place out of 11 entries shown. For those, who are interested, grab the intro: tsunami.tar.bz2, complete with source code. It's under GPL, naturally ;)

On the not-so-nice sides of this years Assembly, I caught some flu there and because of it, I wasn't feeling too well for the time of the party.

And for the rest... Well, I don't know what I should write. And of course, it may not always be the best to write everything for the whole world to see.

It's alive!

I just a while ago committed feMerge support in Inkscape SVN. Now, we have all the parts required to render the example image in SVG specification!

Several other example files are now rendered correctly, too. This filter primitive doesn't bring anything really new, because everything it does, can be done with feComposite, feBlend or even with the simple alpha compositing used in SVG outside filters. It's just an easy way for filter creators to composite several images into one.

Also, check out the Filter effects page in Inkscape wiki. There's a nice listing, which filters work and which don't. There really is a good amount of filters that already work.

Lighting examples

Well, I got around and made an example image with lighting. This utilizes gaussian blur, diffuse and specular lighting and feCompose modes arithmetic and in.

New Inkscape developers

I haven't gotten much code done for Inkscape lately. Small bugfixes here and there, but nothing big really. Most of my time has gone into developing a 4k intro for Assembly 2007 and helping out new Inkscape developers.

Yes, indeed. There are two new guys, who have jumped into developing filters for Inkscape. Thanks to them, we have three new filter primitives implemented in Inkscape: feConvolveMatrix, feDiffuseLighting and feSpecularLighting. Once again, these open up new possibilities for artists using Inkscape.

Now I propably should toss in some examples using these new filters. I don't have any, so I'll toss in the Filter effects example from SVG specification. It shows one possible use for these lighting effects. Actually, Inkscape is almost able to render that one correctly, only feMerge filter primitive is missing.

For feConvolveMatrix then, it can be used for effects like blur, edge detection, embossing, sharpening.

That 4k intro even has a connection to Inkscape: the engine is able to render bezier shapes and I've used Inkscape for designing those shapes. More of that later, so I don't spoil it for anyone ;)

Introducing feComposite

I decided to postpone turbulence filter for a while and go ahead with my original plans. So now, Inkscape has a new filter primitive, feComposite.

Composite in this case refers to Porter-Duff compositing operators, introduced in a paper "Compositing Digital Images" by T. Porter and T. Duff. These compositing operators can provide quite interesting results, though I'm yet to come up with a example where they could be used. Well, one thing useful could be cutting holes to objects, for which using boolean operations would not be feasible.

Reading that paper, so I could implement the filter, a strange feeling of perspective crossed my mind. Even though computer graphics is a rather new area of study, this paper has been written before I was even born. Only a year before, but still.

Creating this filter I came upon several parts of filtering code, that should be simpler to use. Especially handling temporary images requires too much boilerplate code. So next, I will look into improving handling temporary images.

Timidity power usage

A while ago, I tried profiling my computer power usage with PowerTOP. This showed, that Timidity was waking up 100 times per second. As I wasn't using midi for anything at the time, this seemed rather odd. Tracing running Timidity with strace, I noticed that the alsa sequencer interface was polling something.

Digging Timidity cvs tree, I noticed this polling was introduced, when stream tracing support was added to alsa interface. Stream tracing allows for displaying Timidity state in real time, so it can't just sleep until something happens. For normal usage as software midi interface, this is useless. Before this tracing support was added, Timidity did sleep until some event occurred.

So, this patch makes Timidity alsa sequencer interface poll at 100 Hz only, when stream tracing is used. Otherwise, it just sleeps until something happens. This doesn't seem to break anything and considering that it doesn't actually add new functionality, I believe it's safe to use.

The patch: nopoll.diff