Bug 258439

- do you use "accurate" as scale method?
- what window decoration do you use, could the black borders be the shadows?

oh I know this bug exists, since I did changes to not have the black border, 
Thomas did changes to undo regressions introduced by my commit ;-)

I see it on both ATI ARB shader and NVIDIA GLSL shader with Oxygen window 
decoration in both Thumbnails and Present Windows. I think it's just the wrong 
blend func, but did not investigate yet (too busy with ES)

@Thomas using accurate scale method and Oxygen windows decorations.

yes, this fits martins comment and my fears ;-)

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

I'm going to fix it tomorrow

Created attachment 54426 [details]
Possible patch

Thomas could you please test if it still works with NVIDIA? My NVIDIA system is just running Nouveau with GLES (so no Lanczos at all)

Created attachment 54432 [details]
Fix better

nope :-(
sorry, i wanted to and should have come back on this before...

From what i can say the issue is (here) likely(?) on (the effective?) GL_DEPTH/(internal)format of GL_SRC:
- solid clients work fine in all occasions
- using "alpha = true" works fine with ARGB textures (the decoration, argb clients using bespin/qturve/oxygen) but fails with _NET_WM_WINDOW_OPACITY < UINT_MAX
- using "alpha = false" works fine with _NET_WM_WINDOW_OPACITY < UINT_MAX, but fails with argb windows & textures (ie. konsole - hard to see with linux colors...- as well as decorations - ie. you get black corners on translucency enabled decorations, better noticed with a bright wallpaper...)

=> my Q'n'D solution would be attached
it removes the opacity multiplication, but relates "alpha" to _NET_WM_WINDOW_OPACITY, the only remainig problem is the decoration on such clients, but it's better (here) as everything else we currently have...

On Saturday 11 December 2010 17:24:50 Thomas Lübking wrote:
> => my Q'n'D solution would be attached
> it removes the opacity multiplication, but relates "alpha" to
> _NET_WM_WINDOW_OPACITY, the only remainig problem is the decoration on such
> clients, but it's better (here) as everything else we currently have...
This one is causing black flickering of decorations when I use highlight 
windows on thumbnails. In that case we have an ARGB deco and opacity != 1.0.

I think we just need different blend funcs for the different cases as I did 
for the shader case in scene_opengl. And as soon as my GLES branch is merged 
we can render the cached texture through the ShaderManager (see [1]) and can 
get rid off the prepare rendering stages at all.

[1] http://gitweb.kde.org/scratch/graesslin/kwin-
gles.git/commit/da259f9dd5ed0004cc33b4e909af8f43e3d19e81

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

Created attachment 54448 [details]
Exclude black shadow

And another try. This is no an iteration on the last patch excluding the decoration shadow. With that we just have a small black pixel in the corners of the windows and translucent decorations are probably bleded against a black background. But I guess it's the best we can get currently.

Thomas, can you please test if everything is still working for you? If yes I will commit this one.

yeahno... actually i hadn't seen what seems to be either a rounding issue or a weird behaviour of the nvidia driver.

while highly translucent ARGB clients work nice with this patch (except for the black corners) _slight_ translucency + ARGB causes the entire window to be backed black.... .... ....

i wonder if it would be sane (if we cannot fix it otherwise and maybe better than removing shadows) to either ignore the opacity (fade in during animation) or not use the lanczos filter on _NET_WM_WINDOW_OPACITY translucent windows at all (assuming that because of the transparency the client won't be "readable" anyway) - maybe casual (ie opacity < 0.7 -> no lanczos, opacity > 0.7 -> make opaque) *shrug*

Yes, that is a good ides: no lanczos for (opacity != 1.0). That should solve 
all remaining issues.

Also when those black borders once appeared when I installed 4.6, the present window effect is so slow when showing up/being closed or when windows are added/hidden (i.e. when filtering). The hover effects are extremely smooth but it lags as hell when the present windows grid is being opened/closed (i.e. the windows are scaled down)

> Also when those black borders once appeared when I installed 4.6, the
> present window effect is so slow when showing up/being closed or when
> windows are added/hidden (i.e. when filtering). The hover effects are
> extremely smooth but it lags as hell when the present windows grid is
> being opened/closed (i.e. the windows are scaled down)
Please do not mix reports. This bug is about the black borders which is 
completely unrelated to the performance problem (which is already fixed).

Created attachment 55027 [details]
exclude translucent windows from lanczos

So here comes the broad sword approach.
It works on nvidia, please test on other GPUs/drivers (i can test nouveau later on, currently don't run the GL supporting version)

Created attachment 55036 [details]
Exclude shadow and translucent windows from lanczos

Slight change to remove the black shadows. Works fine on fglrx

since the original report resulted from "alpha = false", do we still need to clip shadows with "opacity == 1.0" and "alpha = true"? 
(it works here, does it break on fglrx?)

You are right, it's not needed any more. Just tested and it is fine

@Thomas: could you please commit your patch from comment #16?

SVN commit 1207826 by luebking:

exclude non opaque (NOT "non ARGB") windows from lanczos filter unless we've a working blendfunction for the cached texture
BUG: 258439


 M  +2 -3      lanczosfilter.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1207826

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