Summary: | translucency effect causes zombie when closing a window (likely due to multiple and uncancelled "set" calls) | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Gao yang <gaoyang4425> |
Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | azou8506, bob.mt.wya, georgo10, graham.allott, michael, stuartksmith, tajidinabd, thomas, vmorenomarin |
Priority: | NOR | Flags: | mgraesslin:
ReviewRequest+
|
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
URL: | https://phabricator.kde.org/D3190 | ||
Latest Commit: | http://commits.kde.org/kwin/94c5704af74db5e0f8e86f0c572e4e11453e7002 | Version Fixed In: | 5.8.3 |
Attachments: |
what happens if I alt-tab
kwin supportInformation Settings of transparecy This also brock the ghost window KWin support information KWin Support Information qdbus kwin supportInformaton |
Description
Gao yang
2015-01-11 02:27:34 UTC
Created attachment 90335 [details]
what happens if I alt-tab
Looks like a repaint issue. Does the area "clear" when you move another window across it? Please attach the output of qdbus org.kde.KWin /KWin supportInformation I don't know how to do with this problem, but this is really annoyed because I have to close Firefox before logout or shutdown. like this? http://paste.ubuntu.com/11722977/ Created attachment 93193 [details]
kwin supportInformation
Please do not use paste services for bug reports (risk to loose the information)
You didn't answer whether moving another window around that area clears the scene.
(it's important to know whether kwin thinks the window should be there or just forgets a repaint)
As for potential causes, try to
a) disable the translucency effect
b) slow down animations
c) disable "suspend compositing for fullscreen windows" (all in "kcmshell4 kwincompositing")
and please report whether either of that has some impact.
I tried this steps and I found out it happens when I enable "suspend compositing for fullscreen windows" and translucency together and it won't happen with either of them enabled. No, this problem just happened when I enables translucency only. Maybe this problem is related to Nvidia graph card I think. We really need to make scripted effects print out thei config ;-) a) please make a screenshot of the translucency effect config dialog (and attach it) b) prettyplease state whether causing repaints in that area (eg. moving round *another* window there) removes that artifact. Created attachment 93221 [details]
Settings of transparecy
That window is just above desktop and below other window. I can check the files on the desktop but I can see them because they hide behind it. It cannot select by alt-tab and it flash and broke when I use alt-tab as can see in the first picture. Try to set 裝飾 to fully opaque (the setting is gone in KDE5, can't try myself) About the other thing: let's try to redesign the question ;-) Does BE::Clock automatically reveal its area below the ghost window (when it updates the time) or does this only happen after using alt+tab? I tried set that fully and this problem did not happen. But after I set that not fully this problem did not happen for three times. Maybe this problem just happens randomly. BE::Clock do not automatically reveal its area. Created attachment 93233 [details]
This also brock the ghost window
I can confirm this issue. I am using kwin 5.6 from Arch Linux (same problem with 5.5). I had the transparency plugin in kwin enabled and configured dialogs to be transparent. When closing a dialog window (like the konsole profile settings dialog), it would always remain as a ghost window. Moving another window above it did not change anything. The only fix is to disable and re-enable compositing. Maybe related: The plasma task bar also sometimes gets stuck, so that tray icons don't get updated. Note that this only seems to happen with Intel drivers, not with Nvidia. It also happens independently of kwin compositing settings: I tried both EGL and GLX, OpenGL 2.0 and 3.1, and various VSync settings. After reading this bug report, I learned that disabling the kwin transparency plugin is a solution for the problem. Created attachment 98109 [details]
KWin support information
*** Bug 363923 has been marked as a duplicate of this bug. *** *** Bug 349020 has been marked as a duplicate of this bug. *** looking at the translucency animation effect, "startAnimation" resp. "checkWindow" should most likely "cancel" all present animations, otherwise a VD change will likely cause a multiinvocation what leaves the old "set" calls dangeling (thus the window referecend) Created attachment 99616 [details]
KWin Support Information
I can reproduce this bug on both Arch with Plasma 5.6.5 and Gentoo with Plasma 5.6.95 (see Gentoo Kwin Support information attached).
Simply enabling translucency for Dialogue windows (only) is enough to trigger the issue.
Undirect fullscreen windows - makes no difference.
Global Animation Speed changes - makes no difference.
Disabling and Enabling compositing removes the "ghost" windows. Otherwise the "ghost" windows just hang around (on all desktops). They cannot be interacted with and get overlaid by other Windows - as these are given focus.
I have the same issue with both an intel card and and AMD card I began noticing this after upgrading to unstable neon this weekend from ubuntu 16.04 stock, where I'm getting ghost windows when removing them. I am also seeing translucency not restoring to non-translucent on active windows at times. Both cases, I usually hot-key restart compositing, and it behaves again for a few hours. I use this as well with dimming, going to try without dimming to see if some combination of both. Posting support info as well if it helps. Created attachment 100362 [details]
qdbus kwin supportInformaton
*** Bug 369340 has been marked as a duplicate of this bug. *** Git commit eb88762e0793b7f4f3facbaccb6a783370d6ee0e by Martin Gräßlin. Committed on 28/10/2016 at 12:37. Pushed by graesslin into branch 'Plasma/5.8'. [autotests] Add test case for translucency effect of dialog window This test case simulates a condition of the translucency effect modifying windows of certain types (e.g. dialogs). In case the effect got activated for a window it does not end after the window gets closed and creates a non-interactive zombie window. M +74 -7 autotests/integration/effects/translucency_test.cpp http://commits.kde.org/kwin/eb88762e0793b7f4f3facbaccb6a783370d6ee0e Possible patch at https://phabricator.kde.org/D3190 For those who want to use it directly. The change is only in the javascript file. You can modify the installed file on your system and perform the same change. Restarting kwin afterwards should be sufficient to get the fix in. Git commit 94c5704af74db5e0f8e86f0c572e4e11453e7002 by Martin Gräßlin. Committed on 28/10/2016 at 14:24. Pushed by graesslin into branch 'Plasma/5.8'. [effects/translucency] Cancel existing animations before starting new Summary: It can happen that startAnimation is invoked multiple times for a window. In case it was invoked a second time the previous animation was not cancelled. This resulted in the set-animation to never end. When closing a window, it would stay around as a translucent, non-interactive window zombie. This change ensures that existing animations get cancelled. FIXED-IN: 5.8.3 Test Plan: Tested through autotest and manually. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3190 M +0 -3 autotests/integration/effects/translucency_test.cpp M +3 -0 effects/translucency/package/contents/code/main.js http://commits.kde.org/kwin/94c5704af74db5e0f8e86f0c572e4e11453e7002 |