Bug 108194

this is no "proof of concept", but a mockup...
anyhow, i'm planning to allow the whole deco to be translucent, while the content stays opaque (let's see if we can have different levels of opacity)
the distorsion however will need an GL XServer or (extensions to, full HW implementation of, better) XRender, as smoothing (distorsion, gauss blurr) is horrible slow on SW (for realtime purposes)

You're right, it's only a mockup. Sorry for the misrepresentation.

Everything you said sounds right on track! I guess another challenge (if we are to mimic the Plastik theme) is to not only change the opacity of the region surrounding the buttons, but to do it smoothly/gradually.

There is a start to this as far as the window decoration portion over at kdelook.org.
Crystal:
http://kdelook.org/content/show.php?content=13969
Crystal GL:
http://kdelook.org/content/show.php?content=18983

To get the style to match would be the hard part, but I just wanted to point out that someone had done some work on this for us to expand upon.

this deco uses fake translucency (i.e. the wallpaper) and the key problem is that X doesn not operate on GL textures, so you'd need to:
- transform the X pixmap into a GL texture (slow)
- perform the GL action on that texture (fast, depending on your HW)
- retransform the updateted texture into a X pixmap (slow again)
and that is somehow to slow at all for realtime usage

as we don't get full XRender HW support from the GPU vendors and maybe some extensions to XRender an openGL X backend may be the only usable solution to this, but a lot of X key developers seem to do not really like that idea (and a lot of ppl don't like the CSS XServers as well...)

and before anyone states: "but M$ can do that, do you say linux is not as good as M$ ;)"
1. this is not linux but X (scnr ;)
2. unfortunately the X team cannot just say: "This is directX - support or die!"

however i'm currently passing the control over the window translucency to the decos, current cvs supports translucent decos and opaque windows and as mentioned in later releases the deco may ask for gradients or other functions on this
fully and *stable* ARGB support (i think Qt4 has?) together with an improved COMPOSITE extension will bring even more translucency to your desktop

I've read your discussion on how to create blurring without relying on the computationally-intensive Gaussian formula:
http://baghira.sourceforge.net/blurring.shtml

This is just an idea, but would randomizing the pixel shifts within a given range make the blur more realistic? Something like this:
1.The original (opaque) 
2.Shifted rand(1,3)px up, rand(1,3)px left (50% opaque) 
3.Shifted rand(1,3)px down, rand(1,3)px right (50% opaque)

i assume you mean per pixel? (otherwise the answer is strictly no, adjusting the displacement value to the resolution could be usefull)

yes, may be - but XRender simply doesn't give that currently (if you call XRenderComposite for every pixel, however you'll very soon get a problem -function calling hast some costs as well ;)

but thanks for promoting my short article (full of typos, though ;)

Long time no comment to this feature request... it's actually available :-) With KDE 4.3 you can have translucent window decorations. There are theme engines available which support translucency.

I am not sure the author of this wish is satisfied with transparency only, given that blur has been removed from 4.3

I think this wish should keep open. Or is there a wish to add blur to KWin?

(In reply to comment #8)
> I think this wish should keep open. Or is there a wish to add blur to KWin?
That blur has been removed has actually nothing to do with decorations. I consider removing of blur as a regression and of course we want to have a nice and good working blur effect in 4.4.