blur[12] - #252

How does this compare to #151?

How does this compare to #151?

The API is different:

1. you don't have setters and getters for the options, but just a direct function call.
2. The array is blurred in-place and returned, so you have to be careful and do B = blur1(A.slice(), 3)
3. There are two signatures blur1 and blur2, depending on whether you want 1-d or 2-d blurring.

Fractional blurring (for example, r = 1.5) is much more balanced (see Mike's demo)

In terms of performance the difference is impressive: Mike's new implementation is 6 to 8 times faster than mine in 1-d [tests]; similar results on macos Chrome, Firefox and Safari.

I'm surprised both by the huge performance boost in 1-d and the fact that it doesn't result in hugely better performance in 2-d (“only” 30% faster—which is already a big win). Maybe what's slowest is the number of copies?

I think I'd want blur1 to be renamed blur, with a default r = 5, so I can write blur(A).

#254 adds the stride.

I think I’ve got it working with a circular buffer of size 2 * radius + 1, eliminating the need to copy the entire input values array. That should make the performance even better. I’ll push more changes later today.

How does this compare to #151?

I think this is pretty well covered in the top description? If you have more constructive questions, please ask.

My aim with the question was to illuminate how this implementation compares and contrasts with the other. The top description describes this implementation only, without any comparisons or references to the other, so at first glance it was not clear what advantages this implementation has over the other. Thank you @Fil for thoroughly addressing my query - that's exactly the kind of information I was looking for. Thank you both for your amazing work!

The top description describes this implementation only, without any comparisons or references to the other

I strongly disagree; the description enumerates the changes in this PR versus the other branch.

Ooooohhhh! Sorry, I didn't realize that. My mistake. Thank you for clarifying.

Here's a benchmark https://github.com/d3/blur-benchmark

Overall the circular buffer is quite faster on larger arrays, but a bit slower on medium-sized arrays.

I’m seeing that the circular buffer is quite slower than the copy in Chrome, so given the added complexity of this approach I’m going to unwind the latest commit and stick with the original approach.

I still want to think about strides and RGBA blurring but otherwise this PR is ready for review.

I wrote an adapter to make the blur functions work for RGBA image data:

function blurfImage(radius) {
  const blur = blurf(radius);
  return (T, S, start, stop, step) => {
    start <<= 2, stop <<= 2, step <<= 2;
    blur(T, S, start + 0, stop + 0, step);
    blur(T, S, start + 1, stop + 1, step);
    blur(T, S, start + 2, stop + 2, step);
    blur(T, S, start + 3, stop + 3, step);
  };
}

Otherwise the algorithm is the same. Hooray!

I’m quite happy with how this turned out. I hope you like it, @Fil! 😅

I'd like to rename blur1 to blur, have r default to 5, and make height optional since it's redundant information.

Hmm. I’m okay with the rename.

I don’t see a lot of value in having a default for r; when would you want to blur with a default radius, and why is 5 the right default? The CSS blur doesn’t have a default. https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/blur

Making height redundant seems okay, although there’s something to be said for being explicit.

Also, it seems this version doesn't support iterables… is it something we might want to add back (with arrayify?).

No; you can’t modify an iterable in-place as you need to be able to assign indexed values, not just iterate over them. If you have an iterable, you’d need to convert it into an array first yourself.

when would you want to blur with a default radius

When I compute the laplacian of a slow moving value (no high frequency), the radius is just a scaling factor. Not a big issue.