Version: (using Devel) Installed from: Compiled sources OS: Linux Steps to Reproduce: 1. Run KWin with compositing and shadows. 2. Set a window to "Keep above others" 3. Open a menu so that it covers an edge of this window. The shadow of the window is still drawn above menu, although the menu is above it.
Created attachment 25339 [details] screenshot A screenshot of the problem.
Caused by the queueing and delaying of shadows in the effect, but I haven't found out the problem exactly.
*** Bug 172589 has been marked as a duplicate of this bug. ***
Update: The bug is still present in trunk for me and appears to no longer require Keep above others.
*** Bug 178478 has been marked as a duplicate of this bug. ***
*** Bug 179670 has been marked as a duplicate of this bug. ***
*** Bug 177267 has been marked as a duplicate of this bug. ***
Is it too much of a workaround to check in ShadowEffect::drawWindow if the window has the Keepabove flag set and set the variable optimize accordingly? It should not be a huge overhead, how many windows would have that flag set anyways? I tried, but could not find how to check for the keep above property.
*** Bug 181518 has been marked as a duplicate of this bug. ***
Just noticed something rather interesting. If there is a panel the bug is not reproducable. If the panel is autohidden, the bug is reproducable.
I have this bug on KDE 4.2.1 (Qt 4.5.0), but the "Keep above others" options isn't needed to reproduce it. My Panelis set to "Windows can cover" if i set it to "Always visible" the shadows are drawn correctly again.
I can confirm this as well: the problem seems to be with the, "fade" effect. When this is switched off, the shadow remains under the, "keep above other" windows.
Actually, after further experimenting, it still takes effect with the fade plugin off: both with Amarok 2's OSD and Plasma's right-click context menu.
*** Bug 190258 has been marked as a duplicate of this bug. ***
*** Bug 182875 has been marked as a duplicate of this bug. ***
just stumbled across this - should be long time fixed. can anybody still reproduce this?
Still reproducible on today's trunk. Use Shadow plugin together with a decoration that does not provide its own shadows, and open a pull down menu that extends outside of the window borders, e.g. with the Oxygen widget style.
hummm... tried Sculpture ;-) and KDE2, no show effect (like fade), translucent and opaque popups on translucent and opaque windows, active and inactive windows, rmb of kwin and the client -> no success :-( (no, i did not forget keep above ;-) <advert> can you go here: http://kde-look.org/content/show.php/BeShadowed?content=121607 and check whether it shows the same problem? (though it has more or less the same keepabove exception...) </advert>
Sorry, I only looked at the screen shot. When you enable "Keep above others", it works fine, but when you just use a normal window with Shadow effect and have a pull down menu in Oxygen style then the same bug shows.
The shadow effect is also having problems when the blur effect is enabled, with shadows often not being painted at all or only partially painted. I haven't investigated why yet, but it's likely related to windows being painted bottom to top instead of top to bottom.
*** Bug 237684 has been marked as a duplicate of this bug. ***
The shadow plugin has also slowed me during all the KDE 4.4 cycle, and with KDE 4.5 I am also experiencing a several seconds delay between a menu appearance and the draw of its shadow. The problem is so severe that I simply gave up with the shadow plugin and turned to an alternative. BeShadowed, http://kde-apps.org/content/show.php/BeShadowed?content=121607 , does shadows several times faster than KWin shadow plugin, and has no slowdown when interacting with other effects. Obviously, it still doesn't work under KDE 4.5 Beta 1.
can you confirm that _this_ very bug (ghost repaints on popups) is solved by the BeShadowed fork?
Tried to reproduce using the "Steps to reproduce" header. I couldn't reproduce this with KDE 4.4 and BeShadowed 0.7; the menu draws perfectly even when a window requests to remain on top.
kde4 is doomed... just stop using it! I have learned to ditch it finally! It was painful but worth it. d i n o k o r a h Tel: +44 7956 66 52 83 On 27 May 2010 13:51, Alejandro Nova <alejandronova@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=164084 > > > > > > --- Comment #24 from Alejandro Nova <alejandronova gmail com> 2010-05-27 > 14:50:57 --- > Tried to reproduce using the "Steps to reproduce" header. I couldn't > reproduce > this with KDE 4.4 and BeShadowed 0.7; the menu draws perfectly even when a > window requests to remain on top. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
(In reply to comment #25) > kde4 is doomed... just stop using it! > I have learned to ditch it finally! It was painful but worth it. > What exactly is this in aid of? This isn't a forum, it's a bug tracking system.
And to aid in understanding the bug, we've established: 1. The shadows that produce this bug are KWin's rather than the Oxygen window decoration's built-in shadows; 2. The shadow affects windows without the keep-above option set, but doesn't affect windows with the keep-above option set; 3. It affects every widget style, not just Oxygen widget style (I've just tested this); 4. It seems consistent across graphics hardware - I've tested this on both NVidia graphics cards with proprietary drivers and an Intel Atom N270 integrated graphics with open-source graphics drivers 5. It doesn't affect the third-party BeShadowed fork at http://kde-apps.org/content/show.php/BeShadowed?content=121607
@ comment #27: That seems to be exactly what is happening to me. I thought it was GTK only, but I think I caught it a few times doing this to me on other apps, so I don't think it's rooted to GTK only. Would love to see this fixed!
I've tried very hard to replicate this bug with KDE SC 4.5 Beta 1, but I can't. I'm following every step. 1. Force Oxygen window decoration to use window effects shadows. 2. Get a window and force it to "Keep above others". 3. Right click somewhere, to get a menu that intersects with the shadow and with a window border. With KDE 4.5, I'm getting perfect results also with the normal Shadow plugin. BeShadowed doesn't compile nor work with KDE 4.5, so it's impossible for me to use it. Maybe something somewhere else fixed this for good. Can somebody retest and confirm?
> I've tried very hard to replicate this bug with KDE SC 4.5 > Beta 1, but I can't. I'm following every step. This could be related to the blur effect being enabled by default. Could you please try to disable the blur effect and see if you are then able to reproduce?
I didn't have blur enabled! With blur, I couldn't reproduce this. Without blur, I couldn't reproduce this. With blur, I got a several seconds delay with the shadow. Without blur, I got no delay. But I can't reproduce this! If there's anyone else with KDE 4.5 beta 1, please, test and confirm. Maybe, really, something somewhere else fixed this bug for good.
Couldn't reproduce following the steps desribed in comment#29. Running trunk, actualy, a few days old, but still it's trunk.
I could reproduce this bug, KDE 4.5 beta 1, but this is weird, guys... ¡Plasma Desktop is working around somehow this bug! I opened VideoLan Player (Qt Interface) and tried to close a bogus and buggy additional window spawned by the poor systemtray support of that player. Plasma Desktop crashed, and, while it was crashed, this bug manifested. But Plasma Desktop relaunched and the menus magically appeared themselves fine, without this bug. I said that something somewhere fixed this. Now I can tell that Plasma Desktop IS WORKING AROUND THIS BUG, BUT IT IS STILL THERE AND THERE ISN'T A PROPER FIX FOR THIS.
gotcha! the reason is that at least the stack index of popup menus seems to be bullsh...errr "unreliable" ;-) therefore the code that paints queued shadows skips the flush (for translucent popups, otherwise the region is shaped away anyway) and then you get an unconditional flush of all queued shadows at the end of the cycle (painting the window shadow untested above the popup) desktop type widgets (it's not related to plasma in particular) get a special position in the renderpath that seems to implicitly flush or fix the popup index (not tested) i could fix this (for BeShadowed)
Great! I should've mentioned my menus were translucent... Any chance of a full fix? At least in KDE 4.5 at the lowest, I just want to know it'll be fixed somewhere. :-)
I think it's especially important that it gets fixed in 4.5, because 4.5 gives users the ability to use KWin shadows instead of Oxygen shadows. ... Please?
4.5 final has been tagged, but this bug is still present in KWin's built-in shadow effect (using 4.4.92). Does this mean it won't be fixed until 4.6?
Git commit 3b8984d630cc6dc655a171fa9c0f7e74e9ee3c61 by Martin Gr����lin. Pushed by graesslin into branch 'graesslin/kwin-cleanup'. Remove Shadow Effect. The shadow effect is known to be broken since at least 4.5. It is unfortunately in a state which makes it difficult to maintain and the architecture has some serious drawbacks. Therefore it is the best solution to replace the effect with a new and better implementation. For more information about the new implementation please see the discussion on KWin mailinglist: http://lists.kde.org/?l=kwin&m=129607406517609&w=2 This also "fixes" all existing bug reports about the shadow effect. Most of the bugs will really be fixed when the new shadow system is implemented, if not it is a new bug and a new report should be created for it. Please excuse that we go this unnormal approach to mark bugs as fixed with code removal. BUG: 164084 BUG: 160948 BUG: 189241 BUG: 229164 BUG: 258663 BUG: 216709 BUG: 243890 FIXED-IN: 4.7.0 M +0 -1 kwin/effects/CMakeLists.txt M +0 -7 kwin/effects/configs_builtins.cpp D +0 -31 kwin/effects/shadow/CMakeLists.txt D +0 -786 kwin/effects/shadow/shadow.cpp D +0 -166 kwin/effects/shadow/shadow.desktop [TRAILING SPACE] [TRAILING SPACE] D +0 -102 kwin/effects/shadow/shadow.h D +0 -128 kwin/effects/shadow/shadow_config.cpp D +0 -91 kwin/effects/shadow/shadow_config.desktop D +0 -57 kwin/effects/shadow/shadow_config.h D +0 -258 kwin/effects/shadow/shadow_config.ui D +0 -70 kwin/effects/shadow/shadow_helper.h M +0 -4 kwin/kcmkwin/kwincompositing/main.cpp M +9 -20 kwin/kcmkwin/kwincompositing/main.ui http://commits.kde.org/a5d5b61a/3b8984d630cc6dc655a171fa9c0f7e74e9ee3c61