On KDE4 setting the animation speed in system settings -> desktop effects to fast or very fast results in shadows around windows to persist even after the window it belongs to closes. SysInfo: - arch x64, using latest stable packages - nvidia-340xx driver (340.76-2) used, nvidia 260GTX GPU - kwin --version: Qt: 4.8.6 KDE Development Platform: 4.14.5 KWin: 4.11.16 Reproducible: Always Steps to Reproduce: - set animation speed to fast or very fast - trigger a notification (i.e. deadbeef next song notifications) - let the notification disappear - OR: open the application menu and close it again Actual Results: The shadow will still stay until you move over it with the mouse cursor/other window Expected Results: The shadow should disappear once window closes Using default oxygen skin for both Qt and GTK applications, the shadows persist for both and it also does not matter what is "below" the shadow. If it matters, I'm using a vertical taskbar on the left side of the screens. Multiple monitors used, but disconnecting all but one does not change anything. Disabling all effects stops the bug from appearing. I am pretty sure the fast/very fast animations worked fine before on another PC (also with an nvidia gpu+driver) before, but I can't test it anymore because it runs kde5 now.
Just tested on another PC with an ATI 6130 GPU running the xf86-video-ati driver, same behavior with a horizontal taskbar. The artifact is harder to see on the "fast" setting, probably because the animation is closer in speed to "normal". Maybe the shadow animation speed is not being correctly set?
Sounds like bug #342085
Created attachment 91185 [details] screenshot of the broken shadow (very fast animation speed)
I'm pretty sure that it's the same bug - I assume it doesn't happen w/ the KDE5 version?
Sorry, I can't seem to be able to find an "animation speed" setting on my KDE5 PC, so I can't really test. But it doesn't seem to occur on default settings (just like with kde4) Just making sure, but does that mean that it's been fixed in KDE5 and won't be fixed in KDE4 anymore?
"kcmshell5 kwincompositing" - there's an "animation speed" slider. kde-workspace SC4 is only open to security fixes (yes, means wontfix in SC4), sorry.
Yes, doesn't seem to be appearing at any position of the animation slider. Too bad about it not getting fixed in SC4. I guess I'll wait until all apps are moved to kde5 and use instant animation speed in the meantime...
The bug should occur w/ "instant" as well (you could rather simply deactivate the minimize/slide effects) The patch could probably be easily backported by your distro - just upstream policies say "security fixes only", downstream can do whatever pleases them ;-)
I did not manage to trigger it with instant animation so far. If it does appear, it's not visible. Doesn't the popup say animations are essentially disabled at that setting?
yes, are - but the layer repaint (of the visible rect) would still be missing. Does this only happen with windows that slide (in and out) or also such that fade and/or minimize?
I haven't noticed it happening to anything other than the notifications or the application menu so far. The minimizing/fade seems to work as expected.
After a crash course to patching things and arch's makepkg, I have added that line to the Client::map() function as in the commit that fixed bug #342085 and recompiled kdebase-workspace (verifying that part of the function looks the same) and it did not fix the issue.
(In reply to Soukyuu from comment #12) > and recompiled kdebase-workspace (verifying that part of the function looks > the same) and it did not fix the issue. Yes. No. Sorry. After comment #9 and comment #11 it's pretty much clear that this is a different bug (slide effect only and only for "brief" animations) which may or may not be still open in KWin/5
*** Bug 346789 has been marked as a duplicate of this bug. ***
I have this issue and have add it since pretty much the 5.0 release. I am on Arch (testing) with the latest stable releases of Plasma/Frameworks/QT, and the latest stable NVIDIA binary driver. This seems to happen for both the menu and the system tray notifier. Another Arch user seems to have it, too: https://bbs.archlinux.org/viewtopic.php?pid=1579808#p1579808 When I get home, I will try to see if I can get a recording of it or something (currently at work). Let me know if I can provide anything else - as this bug just makes KDE seem slow/janky when its actually not :)
Could easily be bug #320892, there's a patch if you'd like to try.
I pulled down the kwin 5.4.3 tar and applied that one liner, removed my arch package (ignore deps) and then installed my compiled version. I saw no change in behaviour, so perhaps they are different? I have attached two of my own screen shots. Also note that this can happen before it is actually rendered, too - some times I can see the shadow border popup for either Kmenu or system tray menu before it is even painted. So in my screen shot, think that you see that outline -before- it is rendered, and then the actual window pops into. It is more pronounced on closing though, as it just says like that (sometimes is does flicker on/off). Not sure if it is the same bug or not ?
Created attachment 95610 [details] System Tray Outline I can try to capture a video - is there any good software to do this, or would my phone be the best (because its camera definitely isn't).
Created attachment 95611 [details] Menu outline
(In reply to Joe from comment #17) > Also note that this can happen before it is actually rendered, too *before* simply means that the client maps an ARGB window and then takes ages to fill it with some content. Only remaining shadow artifacts would make for an actual bug. The systray popups don't slide out (with slower animations), though, do they?
It happened to me while opening and closing the application launcher Screenshot: http://i64.tinypic.com/im2k4x.png Temporary workaround involves changing the animation speed to instant.
(In reply to Thomas Lübking from comment #20) > (In reply to Joe from comment #17) > > Also note that this can happen before it is actually rendered, too > > *before* simply means that the client maps an ARGB window and then takes > ages to fill it with some content. > Only remaining shadow artifacts would make for an actual bug. > > The systray popups don't slide out (with slower animations), though, do they? Hey, I will try to get a recording tonight when I get home from work. And for it happening before, I want to say its like it draws the entire shadow outline for it being completely rendered, while it is still doing the animation to fill it - I would think the border should go with the animation, no?
@rotationalimbalance, you'll encounter bug #320892 which seems different from this one.
So, before I recorded this, I updated to the Arch KDE-Unstable packages for the 5.5-Beta, and I now have the latest and greatest Xorg release and NVIDIA Driver (358.16). I still have the issue, and recorded it: https://youtu.be/xFftwwxrshA Sorry for the potato, I just decided it was probably the easiest thing to do :) Tried to trigger and demonstrate the full oddness of it (flickering with mouse movement, etc). The initial rendering issue actually seems a bit better on the beta, though. Also note, this only really triggers on the mark right before 'Instant' for animation speeds. On instant it does not, although the drawing speed of the shadow seems to be a bit off and behind the actual menu, and it causes kind of funky flickering from time to time if you click in fast succession, On the 2nd to fastest setting it is still present, but it is actually faded/lighter and harder to notice (if that makes sense). Kind of like in the video where it flickers from full color to faded to not rendering at all. On the middle/default (and slower settings) everything seems perfect. Please let me know if anything else can help. I also believe I cleared out everything in my .config, .local, and .cache when upgrading to 5.5 to attempt to have a clean(er) state to test in.
This looks like the former buffer isn't fully marked dirty, thus insufficiently cleared on re-usage. => Setting the tearing prevention to full scene repaints should not show this problem?
Just tried that. It might be a placebo, but I think it made it happen a bit less frequently, but I definitely can still get it to happen.
Sorry, forgot to mention that you also have to convince out of using buffer age: KWIN_USE_BUFFER_AGE=0 kwin_x11 --replace &
Ah, yes, doing this makes it completely go away, hurray. The kind of janky initial load is still there, but I would think that is a different issue.
*** Bug 356515 has been marked as a duplicate of this bug. ***
Git commit 57c9aa9fc03d8af1afd63b43c136894cdef621d2 by Thomas Lübking. Committed on 14/01/2016 at 22:37. Pushed by luebking into branch 'master'. update expanded geometry when slide is done In addition it's required to keep the expandedGeometry alive until the effects handled the deletion Related: bug 318322, bug 320892 REVIEW: 126323 FIXED-IN: 5.6 M +1 -1 effects/slidingpopups/slidingpopups.cpp http://commits.kde.org/kwin/57c9aa9fc03d8af1afd63b43c136894cdef621d2
Thanks Thomas! Any chance of it being back ported as a fix to 5.5 ;) ?
Git commit 87795eef2a71d85680f797fe75404ca1a9a63a10 by Thomas Lübking. Committed on 15/01/2016 at 00:37. Pushed by luebking into branch 'master'. Actually keep the expandedGeometry alive ... until the effects handled the deletion Related: bug 318322, bug 320892 REVIEW: 126323 FIXED-IN: 5.6 M +1 -1 composite.cpp http://commits.kde.org/kwin/87795eef2a71d85680f797fe75404ca1a9a63a10
(In reply to Joe from comment #31) > Thanks Thomas! Any chance of it being back ported as a fix to 5.5 ;) ? Given the actual age of the bug (since 4.6?) and the (small - I don't think there's, but those are famous last words ;-) potential for an ugly unexpected regression by required postponing of the deleted event, it's unlikely that we're gonna backport this for 5.5, sorry.