Bug 295055 - AbilityUsesAlphaChannel broken when used with shadow pixmap hints
Summary: AbilityUsesAlphaChannel broken when used with shadow pixmap hints
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: kdecorations (show other bugs)
Version: git master
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-29 10:06 UTC by Hugo Pereira Da Costa
Modified: 2013-01-09 09:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hugo Pereira Da Costa 2012-02-29 10:06:13 UTC
Version:           git master (using Devel) 
OS:                Linux

Hello,

I've coded use of Shadow pixmap hints (_KDE_NET_WM_SHADOW) in oxygen decorations.

First result was quite deceptive: the title bar flickers (and most of the time is just transparent), as soon as the hit is set.

(Thomas ? remember ? There was a similar issue with ooffice, at the time the "removal" of the hints were not properly propagated to kwin).

Now it turns out that all issues are gone when I drop 
            case AbilityUsesAlphaChannel:
            return true;
from the decoration factory.
(see below for reproducing)

Funny thing also is that even when the above is dropped, the decoration still supports alphaChannel nonetheless. (oxygen uses argb to have beveled round corners; and I also tested with oxygen-transparent)

So: 
1/ what is the purpose of the AbilityUsesAlphaChannel flag
2/ should the above be fixed ?
3/ should the flag be dropped ?


Reproducible: Didn't try

Steps to Reproduce:
1/ checkout the code (and compile)
  cd kde-workspace
  git checkout hpereira/oxygen-shadows
2/ use oxygen window decoration (in principle there should be no issue)
3/ edit kde-workspace/kwin/clients/oxygen/oxygenfactory.cpp
and uncomment line 165 (// case AbilityUsesAlphaChannel:)

Now see all issues with title bar not being painted.

Actual Results:  
- 

Expected Results:  
-
Comment 1 Hugo Pereira Da Costa 2012-02-29 10:46:25 UTC
The screenshot: 
http://wstaw.org/m/2012/02/29/plasma-desktopRj3169.png

PS: also note that neither oxygen nor oxygen-transparent have their decoration buttons drawn. I am not sure why it is so (and it definitly is a regression with respect to the previous preview list). Should I file a different bug report :) ?
Comment 2 Martin Flöser 2012-02-29 14:10:44 UTC
> PS: also note that neither oxygen nor oxygen-transparent have their
> decoration buttons drawn. I am not sure why it is so (and it definitly is a
> regression with respect to the previous preview list). Should I file a
> different bug report :) ?
I am very sure it is completely unrelated, as
a) I would have spotted it while working on it
b) I am very sure that the problem existed either before the change or emerged 
afterwards (I think I have even seen it on 4.8)
c) the rendering code for native deco previews is unchanged - everything is 
still rendered to a pixmap
d) only Oxygen is affected
Comment 3 Thomas Lübking 2012-02-29 14:35:00 UTC
The reason is that with the "decoration" expanded by the shadows a line in
kde-workspace/kwin/scene.cpp and function WindowQuadList
Scene::Window::buildQuads(bool force) const (~ line 586, my version probably
differs) becomes wrong

        QRegion center = toplevel->transparentRect();
-        QRegion decoration = (client &&
Workspace::self()->decorationHasAlpha() ?
                              QRegion(client->decorationRect()) : shape()) -
center;
        ret = makeQuads(WindowQuadContents, contents);
        if (!client || !(center.isEmpty() || client->isShade()))

        QRegion center = toplevel->transparentRect();
+        QRegion decoration = shape() - center;
        ret = makeQuads(WindowQuadContents, contents);
        if (!client || !(center.isEmpty() || client->isShade()))

I'm however atm. not entirely sure whether this is a 100% correct patch (looks
like, though)

See bug #294451 comment #15 - i am sooo much ahead of you ;-)

If we kick the current deco shadow system (deco-but-not-the-deco) we can just use shape. Otherwise we need a hint parameter in decorationRect() or add another function.
Comment 4 Hugo Pereira Da Costa 2012-02-29 15:32:19 UTC
(in reply to comment #2)
Confirmed. Is not working either in kde@4.8
Will investigate. Sorry for the noise.

(in reply to comment #3)
Soo. Do I understand right that 
- removing the AbilityUsesAlphaChannel actually breaks other things (and thus should be kept)
- keeping it is potentially fixable, using the patch above ?

if yes, will the patch be pushed ? 
is it already ?

As for "i am sooo much ahead of you ;-)"
I'm not sure this is a very constructive statement ...
Comment 5 Thomas Lübking 2012-02-29 15:40:39 UTC
(In reply to comment #4)
> Soo. Do I understand right that 
> - removing the AbilityUsesAlphaChannel actually breaks other things (and thus
> should be kept)
Yes.

> - keeping it is potentially fixable, using the patch above ?
Yes, but the patch breaks "legacy" shadows, thus cannot applied be so easily therefore ...

> if yes, will the patch be pushed ?
... not this way.

> As for "i am sooo much ahead of you ;-)"
> I'm not sure this is a very constructive statement ...
I'm not even sure if it's a serious one, but can confirm that it was never intended to be a singular "you", so "you" (this time sg.) were not addressed in particular at all.
Comment 6 Thomas Lübking 2012-04-22 14:32:50 UTC
Umm... this one should actually be fixed in 4.8.2 because visibleRect and decorationRect are correctly split with commit  0f3380f3b10e57416f81a1288dc10b8dfe11d87e

Confirmed?
(at least i re-activated  AbilityUsesAlphaChannel for that version in bespin)
Comment 7 Martin Flöser 2013-01-09 09:20:12 UTC
assumed fixed as of comment #6.