Bug 195593

it looks to me like the bottom texture is inverted in OpenGL and I think I know why.

in Scene::Window::buildQuads we have:
QRegion decoration = (Workspace::self()->decorationHasAlpha() ?
    QRegion(client->decorationRect()) : shape()) - contents;

In case of a shaded window this will be only one rect. That is in makeQuads only one WindowQuad will be created for the decoration and scene opengl get's a little bit confused by this.

I see know two possible ways:
 * we ensure in buildQuads that four WindowQuads are created for the decoration
 * we ensure in scene opengl that the decoration is painted correctly if there is only one window quad and the window is shaded.

Personally I would prefer the first way as there could be quads filtered out so that there is only one decoration quad left. And this would ensure that it also works for XRender (although it seems to work there - which might be pure luck).

Fredrik any ideas?

Created attachment 34500 [details]
Shade window

Hi! When I shade a window and desktop effects are enabled, the decoration is wrongly drawn. Is this the case?

nope, that was another bug (related to ARGB decos and an invalid window region hint) i forgot the id, but it's meanwhile fixed =D

this bug here is rather "minor" and about a slight visual glitch inside the titlebar if the shaded titlebar is bigger than the normal one - unfortunately holds for most decos :-(

@Thomas: are you really sure it has been fixed? What should I update to test the fix? I've updated both kdebase and kdelibs, but the problem is still there... Do you need I open a new bug report about it? Thanks!

actually it appears you suffer from a third bug that only affects the oyxgen/ozone (in fact oxygen instantly segfaults kwin here...) deco but maybe related to this one (rather than to the fixed one)
it just looks more like the fixed bug (the shaded window was not clipped from the window stack and thus the region never got erased - looked similar to the video)

try another deco (e.g. keramik or redmond as mentioned in the original post), it should not show at least such a harsh behavior (usually the bottom is painted inverted)

Created attachment 34512 [details]
modification to kde2-windeco

I modified the kde2 window decoration to get the same effect on there and I don´t do anything suspicious.
Steps are:
* enable AbilityUsesAlphaChannel
* set LM_OuterPadding* to 25
* resize the decoration rectangle
* fill it with something opaque

Created attachment 34513 [details]
screenshot of the kde2-windeco patch

@Thomas: you're right, the bug I've seen is only on oxygen/ozone deco.

(In reply to comment #6)
> don´t do anything suspicious.
except making use of KDecorationUnstable... of course ;-)

the collision between oxygen's intermediate ARGB support (soft corners) and the general ARGB support for decorations is probably (pretty apparent) the reason for this bug. as the ARBG deco afaik cannot be extended to shadows for 4.3 and i don't know whether this collision can be cleared at all.

this may lead to another regression for 4.3 (after loosing blurring) what brings us to release cycle coordination and release cycles at all and another flame war ;-P

(you can even have more fun w/ the oxygen/ozone deco by suspending composition, shading a window, reactivating composition, try* to unshade it...)
*to fix: just resuspend composition, unshade all windows, then resume composition

(In reply to comment #9)
> (In reply to comment #6)
> > don´t do anything suspicious.
> except making use of KDecorationUnstable... of course ;-)
Nope, I use KCommonDecoration in this case.

i'm not sure how kcommondecoration handles this, but the padding handling is part of kdecorationunstable
so if you successfully set paddings i assume kcommondecoration will (silently?) use kdecorationunstable...

what happens if you keep the alpha ability but drop the paddings?

Well the bug doesn´t then doesn´t show up any more of course because the "extra height" at the bottom is the same as the padding.

Just updated to trunk, and I see several errors in the window decorations when running effects. Not sure if they are related to this or not, but they seem related.

If you look at the KDE2 example screen-shot, the color of the button symbols are wrong. When running a unmodified version of the KDE2 deco (or Laptop/keramik etc) the button symbols get the wrong color, actually they get transparency. 

If you play around with several windows and some shade/unshade actions the whole buttons get 100 transparent, but do return when moving the mouse over them. 

Also when shaded, the bottom bar of the window get transparent and about double size of what it should have.

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

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

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

SVN commit 1004690 by graesslin:

When we have a shaded window we have to create the four decoration quads manually. For each deco pixmap there has to be one quad of same size.
This requires some testing and will be backported in two or three weeks.
BUG: 195593

 M  +12 -1     scene.cpp  


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

Thanks for the fix :-)

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

SVN commit 1013299 by graesslin:

Backport rev 1004690: When we have a shaded window we have to create the four decoration quads manually. For each deco pixmap there has to be one quad of same size.
CCBUG: 195593


 M  +12 -1     scene.cpp  


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