I really like the aestectics, even if physically wrong at the edges. Thanks for sharing the details.

As a embedded developer, I feel this is kind of wasteful. Every client computes an "expensive" blur filter, over an over again? Just for blending to a blurred version of the background image?

I know - this is using the GPU, this is optimized. In the end, this should not be much. (is it really?)

<rant> I feel the general trend with current web development is too much bloat. Simple sites take 5 seconds to load? Heavy lifting on the client? </rant>... but not the authors fault

I guess everybody has their own preconceptions of what's wasteful.

I grew up in the era of 14.4k modems, so I'm used to thinking that network bandwidth is many, many orders of magnitude more scarce and valuable than CPU time.

To me, it's wasteful to download an entire image over the Internet if you can easily compute it on the client.

Think about all the systems you're activating along the way to download that image: routers, servers, even a disk somewhere far away (if it's not cached on the server)... All that just to avoid one pass of processing on data you already had in RAM on the client.

This is wasteful and can actually cause perf issues if used really heavily.

I worked on a large applications where the design team decided everything should be frosted. All the text over images, buttons, icons, everything had heavy background blur and mobile devices would just die when scrolling with any speed.

Most of those websites that are technically "wasteful" in some ways, are way more "wasteful" when you realize what we use them for. Mostly it's for pure entertainment.

So either entertainment is wasteful, or if it's not, spending more compute to make the entertainment better is OK.

I would argue that while it _feels_ wasteful to us humans, as we perceive it as a "big recomputation of the rendered graphics", technically it's not.

the redrawing of anything that changes in your ui requires gpu computation anyway, and some simple blur is quite efficient to add. Likely less expensive than any kind of animations of dom objects thar aren't optimized as gpu layers.

additionally, seeing how nowadays the most simple sites tend to load 1+ mb of JS and trackers galore, all eating at your cpu ressources, Id put that bit of blur for aesthetics very far down on the "wasteful" list

Isn't sending both the blurred and non-blurred picture over the network the way we did it since two decades in web dev? With (many!) high resolution pictures this is definetly less performant then a local computation, given that real networks have finite bandwiths, in particular mobile clients on spots with bad wireless coverage. It is astonishing what can be done with CSS/WebGL only these days. We needed a lot of hacks and workarounds in the past for that.

IMO it is time to seriously realise that most of this "ooh looks cool, surely I/we need that" tech has no place in this world. Whether or not the act itself is wasteful (although it generally is in tech...), the thought process itself indicates a bigger problem with society. Why do we need this thing? Why do we consider being without the thing to be bad? Like seriously, at the scale of issues in society today, who cares if your UI panel is blurred or not?

As per the central limit theorem one can approximate Gaussian with a repeated convolution with any function, box blur being most obvious candidate here. And box blur can be computed quickly with a summed area table.

I guess eventually it's a trade-off between doing heavy lifting yourself and paying a little more compute and bandwidth, or offloading it to clients and wasting more energy but at lower cost to the developer. I think there are environmental arguments in both directions (more energy spent computing stuff on the client vs more energy sending pre-computed assets over the networks). I'm not sure which is better ultimately - I suppose it varies case-by-case.

I recently had a shower thought that the bigger you go, more energy you need to do computation. As in you could make a computer out of moving planets. On the other hand you could go small and make a computer out of a tiny particle. Both scales achieve the same result but at very different costs.

Tbh I think people radically underestimate how fast, and efficiently so, GPUs are. The Apple Watch has physically based rendering in the UI. It would be curious to compare the actual cost of that versus using a microcontroller to update a framebuffer pushed to a display via SPI.

I did some webgl nonsense like https://luduxia.com/showdown/ and https://luduxia.com/whichwayround/ . This is a experimental custom renderer with DoF, subsurface scattering and lots of other oddities. You are not killed by calculation but memory access, but how to reduce this in blur operations is well understood.

What there is not is semi transparent objects occluding each other, because this becomes a sorting nightmare and you would end up having to resolve a whole lot of dependencies on this dynamically. (Unless you do things with restricting blending modes). Implementing that in the context of widgets that move on a 2D plane with z-index sorting is enormously easier than in a 3D scene though.

Did my site take > 5 seconds to load?

I put a lot of effort into minimizing content. The images are orders of magnitude larger than the page content but should be async. Other assets barely break 20 kB in total aside from the font (100 kB) which should also load async.