resvg crate now includes a modified copy of the blur algorithm in this crate. Most notably it includes alpha channel support as well RGB/BRG/etc, but also fixes #13.

When I run the example code, the screenshot looks like it was blurred horizontally more so than uniformly.

It should be possible to make the code faster by using iterators instead of indexing, which lets the compiler eliminate bounds checks on every lookup. Using iterators also makes the code more readable.

I have WIP conversion of the horizontal pass to iterators that works and doesn't exhibit any artifacts, but has a higher effective blur radius. It can be found here: https://github.com/Shnatsel/fastblur/tree/iterators
I probably will not have the time to complete it, but somebody familiar with the algorithm should be able to fix the blur radius fairly easily.

Blur radius of 500000000000000000.0 causes a panic in debug mode on overflow. Release mode doesn't check for overflows and doesn't panic.

Isn't this line should contain blur_radius - width?

Lines such as

Specifically, the pixels that require blur to reach beyond the left edge are processed first, with the assumption that they will never need pixels from beyond the right edge in the same operation. So even if it's made to not crash it would produce incorrect results.

Currently, we blur horizontally first, but it produces strange artifacts:

(left - hor -> ver, right - ver -> hor)

Maybe we should blur vertically first?

create_box_gauss() currently returns a Vec<i32> with length specified by the input parameter n. Vectors are always allocated on the heap, which is costly. Even the tiny vectors of 3 elements add 3% to the total runtime, or 6% in asymmetric case that calculates the box twice.

Sadly const generics are not yet implemented in rustc so we cannot abstract it over the length of a slice, but we can work around this e.g. by returning an iterator.

An in-place version would be nice.

This probably has very little effect on the output, but I noticed that the + 1.0 was after the sqrt, whereas the blog post has it inside the sqrt

Original:
let w_ideal = (12.0 * sigma * sigma / n_float).sqrt() + 1.0;

Suggested:
let w_ideal = (12.0 * sigma * sigma / n_float + 1.0).sqrt();