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: -
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 :) ?
> 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
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.
(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 ...
(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.
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)
assumed fixed as of comment #6.