| ▲ | mkbosmans a day ago |
| Do browsers really use a box filter to approximate a gaussian blur? That seems implausible to me, as they produce pretty different looking blurs. |
|
| ▲ | djmips a day ago | parent | next [-] |
| It doesn't seem improbable considering it's a huge performance win and perhaps many won't notice? |
| |
| ▲ | mkbosmans a day ago | parent [-] | | It is the performance win for similar looking results that I find improbable. For a box blur to look like gaussian blur, you would need multiple passes. Even though each pass is now O(1) instead of O(n) (with n the blur radius), due to caching effects I think a gaussian kernel would still be faster, especially for the small blur radius as described in the article. | | |
| ▲ | tyleo 20 hours ago | parent [-] | | The multi-pass box blur effect is the one I've seen in game engines. |
|
|
|
| ▲ | tyleo a day ago | parent | prev [-] |
| Yeah because the GPU has special hardware which you can take advantage of for an optimized box filter. https://www.rastergrid.com/blog/2010/09/efficient-gaussian-b... |
| |
| ▲ | mkbosmans a day ago | parent [-] | | That link is not a box filter, as it still uses weights to approximate a gaussian convolution kernel. It just uses some special hardware to do less texture fetches. But that is a constant 2x improvement over the full 1D convolution, not the box filter O(1) approach that the article suggests that browsers are using. | | |
| ▲ | tyleo 20 hours ago | parent [-] | | You've moved me a place of uncertainty here. I had some confirmation that _some_ browsers use box blurs for this effect, I _know_ some game engines use multiple box blurs to approximate Gaussian blur (having seen the code myself). I updated a few sentences in the article to reflect that uncertainty. Thanks! |
|
|