Translucency: Blurring vs. Speed

Introduction

Having an improved COMPOSITE extension in near future, Qt4 supporting XRender ARGB and faster Computers every single day (i cannot believe what i paid for my poor slow machine, Ok - it was quite fast then... ;) people start to want much more eye candy.

One wish you can see again and again is "etched glass", i.e. some kind of glassy surface that distorts the throughshining light (Compton effect) so the area behind the translucent item appears blurred.

There's one key problem: (Gaussian) blurring is anything but fast!
In a world where the render engine can rely on hardware pixel shaders, this isn't a big problem

<commercial break>
  Has anyone yet seen nVidias 7x00 GPU - geee... WOWW!
</commercial break>

but the current X state is

Painting does not happen in GPU/VRAM (unlike Quartz eXtreme) everything walks through the CPU/Cache limits
XRender isn't as function complete as e.g. directX and especially not fully hardware implemented (e.g. the closed source drivers from nVidia and especially ati)
Writing a compotsite manager that converts every X pixmap into a GL texture, pushes it into VRAM does some GPU operation on it and reconverts the resulting texture into a X pixmap and paints it on the root window will hardly help, as conversion will take too much time for realtime action

You may blame the longtime semi closed development on X, the ignorance of the GPU vendors or an angry god: it's simply a fact and we have to handle it instead of mourning around (maybe the GL X backend attempts will solve this one day - we'll see)

Blurring anyway

The problem: Gaussian blurrage

See this Picture.
The background behind the translucent area was blurred using Gaussian blurr, LZW, and an 8x8 blurr matrix what means that every (center) pixel is influenced by 64 other pixels, so effort is O(64n).
Though this is still linear, TheGimp (using a quite optimized algorithm, MMX+SSE) needs more than a second on my (poor) AMD XP1800 and on this not too big area - this is FAR to slow for realtime action!

Solution 1: Don't blurr

The simple solution on this is to simply not blurr.
The drawback is: it just doesn't look as good as the above picture (while the "Lady"bug is still sexy ;)
The gain of a blurred background is not just the eyecandy but also the readability of the window content. (It's not that bad on this example, but if you've got a translucent textwindow on some other textwindow, you'll get trouble)

Solution 2: use a distorsion map

Another solution is to use distorsion maps.either by the foreground app itself or have the compmanager blend it between the foreground and the background (the client shadows in current kompmgr/xcompmgr versions work as something like this).
The whole this is pretty fast (O(n), plain alphablending is much faster than calculating a gaussian map anyway as every pixelpair is manipulated witha static value) and the current compmanager implementation shows it's usable even with the current (suboptimal) COMPOSITE extension (if the whole thing could operate in VRAM somehow, this would be ultra fast, the limiting factor is still the CPU cache) However, it still does not look half as good as really gaussian blurred background - while this is also a matter of the distorsion map, try e.g, BrushedMetal.

Solution 3: who said we need accuracy

Gauss was a Genius - undoubted. Reading about quantum mechanics, you'll see that the Gaussian function perfectly describes the Compton effect (without explanation, of course: we needed Einstein and Compton for this ;) as any natural likelihood.
But who said we need accuracy in this case? Everything we're interested in is some kind of distorsion, so what i did was alphablending the background three times together:

The original (opaque)
Shifted 2px up, 2px left (50% opaque)
Shifted 2px down, 2px right (50% opaque)

Compared to the blurred original it's not that perfect, but missing a Gaussian benchmark it's quite acceptable (better than the unblurred one or the distorsion map approach imho)
The effort is O(2n), talking about plain alphablending what is really realtime ready (respecting the CPU cache as too strict limit anyway)

Conclusion

Different from what i thought before, blurring seems to be possible anyway - not that nice, but nice enough! (to me)
The key remaining problem is the cache limit - this has especially an impact when moving windows around, as a big area changes very fast so if it only takes place on a part of the window (e.g. translucent frame but opaque content, having relative small areas to operate on) this is really usefully implementable.

Thomas Lübking, 2005