gone for being too buggy.
will be reimplemented and readded later. (hopefully 4.4)

hello!

buggy for whom? It was working very well here! Can it be re-enabled for 4.3 final? 

thanks!

many?
it esp. caused visual glitches after fullscreen effects (ghost framesafter desk switching etc.) interfered with other effects (zoom at least didn't work at all w/ blur enabled, i think there were similar problems with the cube?)

4.3 is fixed, so no.
as for now, it will not be available with this release, sorry :-(

It worked also well enough for me which is why I was puzzled. Any chance to get it back an 'unofficial' way from 4.2 sources?

On Sun, Jul 5, 2009 at 4:49 PM, Ireyon<philip.rebohle@ewetel.net> wrote:
> --- Comment #4 from Ireyon <philip rebohle ewetel net>  2009-07-05 21:49:29 ---
> It worked also well enough for me which is why I was puzzled. Any chance to get
> it back an 'unofficial' way from 4.2 sources?

They only commented an include.

http://osdir.com/ml/kde-commits/2009-06/msg02244.html

The problem for me is: using transpart konsole/yakuake is almost
imposible when blur is disabled. The effect should be put back on but
disabled by default if it so "buggy".

The blur effect was already disabled by default. The reason why I completely removed it the official release is that it was causing hell on this Bugzilla when people did enable the effect.

Doing a very quick search (Inaccurate but meh) of all KWin reports there have been ~80 references to the blur effect, and that doesn't include bugs reported to other programs. That pretty much makes it the buggiest part of KWin and nobody has had the time to fix it yet, thus the removal from source to keep us sane.

The blur effect is awesome and really is good for usability. But it really was very buggy. Made even widgets edges look ugly. Good it is removed but hopefully it would gain some love before 4.4. I hoped it would be keeped for 4.3 and just fixed. Now it takes 6 months again to have it. That is just bad thing for the KDE brand. :(

*** Bug 208860 has been marked as a duplicate of this bug. ***

Is there anything new about the effect? If not, it would be great if it could be re-enabled in 4.4, perhaps with the hint that it is "highly unstable" or so.

(In reply to comment #9)
> Is there anything new about the effect? 
Well I have a new implementation, but I'm still very unhappy about it.
> If not, it would be great if it could be re-enabled in 4.4, perhaps with the hint that it is "highly unstable" or so.
No I think that won't happen. The effect is causing problems and I don't want to ship software which we know that it is broken.

I know worked out where the problem of the old effect was. The blur strength is currently set only once for the whole window rect but it is necessary to render a grayscale mask to a texture.
I currently cannot fix it myself because of too little knowledge in C++ and the KDE API.

Then I've got a diff for the blur-render.frag shader that fixes the problem that the region around the window is too bright. Still quite ugly, but better than before:



@@ -30,11 +30,13 @@ vec4 windowColor(vec2 texcoord)
 void main()
 {
     vec2 blurtexcoord = pix2tex(gl_FragCoord.xy);
-
     vec4 winColor = windowColor(gl_TexCoord[0].xy);
+    // Remove these two lines as soon as the effect works properly
+    if (winColor.a * opacity <= 0.05)
+      discard;
     vec3 tex = mix(texture2D(backgroundTex, blurtexcoord).rgb,
                    winColor.rgb, winColor.a * opacity);

-    gl_FragColor = vec4(tex, pow(winColor.a, 0.2));
+    gl_FragColor = vec4(tex, 1.0);
 }

Maybe it would be easier to do a KWin option to blur everything behind transparent windows instead of implementing it as an effect, e.g. if the windows are finally rendered, copy the window backgrund into a texture and apply a simple shader, then draw the window with the blurred texture.

I've actually been working on a new blur effect this past week that does something similar to what you suggest.

It copies the background into a texture before a window is drawn, and then draws the texture back while blurring it with a shader and clipping it to the window shape.

There's no need to implement this in the core though, because effects can manipulate the background just before a window is drawn by the core.

As Fredrik committed the effect to trunk some weeks ago, I think we can set this report to fixed :-)