Blurring transformed objects is extremely slow

[to0om]

When blurring non-geometrical paths in Inkscape 0.46, it gets extremely slow in comparison to Inkscape 0.45-1. I'm using the SVN revision of march 16th 2008 (revision 17907).

For example: create a simple rectangle and blur it 5%. That is quite fast, even at high zoom levels. Then rotate it a little, say 15 °. Now the rendering is extremely slow. On my machine, it's about 10 times slower than the same operation in Inkscape 0.45-1 (the current stable version). I tried it with different filter quality settings (even with the lowest), but I didn't notice any big difference.

For simple geometrical paths such as non-rotated rectangles the current SVN version seems to be faster than the stable one, but when blurring complex or simple and rotated paths, it's almost unusable, unlike 0.45-1.

I'm using Kubuntu 7.10.

[bbyak (buliabyak)]

afaik 0.45 didn't correctly blur transformed shapes at all, so it's not a fair comparison

[Niko Kiirala (kiirala)]

bbyak is quite close to the truth here. Between 0.45 and 0.46 I changed the method used for transforming filters effects. The new method produces images of higher quality, but with cost of using around 16 times the time, the old method used. The quality difference is not too apparent with blur because it's, well, blurred.

For 0.47, I have plans that Inkscape should have a general 'filter effects quality' setting, instead of the 'blur quality' setting we have now. There, lower qualities would use the old method in addition to calculating the effect for smaller image.

Out of curiosity: how fast a computer you have? I'm trying to pinpoint here, where this slowdown becomes inconvenient.

[to0om (tkonrad-gmx)]

In my opinion, it doesn't really matter if it's a fair comparison or not, because yesterday i had to switch back to 0.45-1 because Inkscape was really unusable with a document i edited (and I suppose the blurring method not to change in the stable version, although I don't know). Moreover, i really didn't notice any difference in the blurring quality.

I'm using an Asus A8JS with an Intel Core 2 Duo processor with 2 x 2.0 GHz and 2 GB of RAM (which is not a too old computer). With the document i attached, it gets really inconvenient at zoom levels higher than 100%.

I'd appreciate it very much to have a possibility to switch back to the "old" blurring method, as the quality difference isn't too big and transformed shapes blur about 10 - 15 times faster here.

[Rygle (rygle)]

Changing to confirmed. Several people here verify and it is mentioned in reply to the 0.46pre4 release.
See here - http://www.nabble.com/Re%3A-Win32-0.46pre4-build-for-testing-p16360675.html
And here - http://www.nabble.com/Re%3A-Win32-0.46pre4-build-for-testing-p16361644.html

Should we add this to the known issues for 0.46 and milestone for 0.46.1?

[Rygle (rygle)]

Added to known issues by Bulia, and slightly tidied up by me (mainly added LP #)

[Peter Moulder (pjrm)]

Some preliminary thoughts:

The x,y standard deviations of the gaussian blur can be seen as defining an ellipse (which is a contour of the blurring). If, after affine transformation, this ellipse is still a circle or an "axis-parallel ellipse" (i.e. something one can draw with the ellipse tool without applying transformations), then the transform of the blur of the object can be done as a blur of the transform of the unblurred object, where the x,y standard deviations of this blur are the x,y "radius" lengths of the transformed ellipse.

If, rather, the axes of the transformed ellipse aren't horizontal & vertical in the rendered bitmap, then one can shear the object in the opposite direction (i.e. the inverse of the shear) in each dimension, then blur, then shear back. However, the problem is that one ought to render to "sheared pixels" for the pixels to be square again after shearing back. If we instead render to square pixels before shearing back, then this approach is lossy. However, the loss shouldn't be noticeable if the blur standard deviation is many pixels.

[Niko Kiirala (kiirala)]

Fixed in SVN. In Inkscape settings, there is now a Filter Effects quality setting. Anything below highest quality will use nearest neighbor filtering when transforming images (that is, the one from 0.45). Bitmap export will still use the best quality, regardless of this setting.