Bug 342716 - translucency effect causes zombie when closing a window (likely due to multiple and uncancelled "set" calls)
Summary: translucency effect causes zombie when closing a window (likely due to multip...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: git master
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://phabricator.kde.org/D3190
Keywords:
: 349020 363923 369340 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-11 02:27 UTC by Gao yang
Modified: 2016-10-28 14:25 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.8.3
mgraesslin: ReviewRequest+


Attachments
what happens if I alt-tab (491.96 KB, image/png)
2015-01-11 02:30 UTC, Gao yang
Details
kwin supportInformation (5.48 KB, text/plain)
2015-06-16 07:22 UTC, Thomas Lübking
Details
Settings of transparecy (38.47 KB, image/png)
2015-06-18 03:07 UTC, Gao yang
Details
This also brock the ghost window (288.19 KB, image/png)
2015-06-19 09:51 UTC, Gao yang
Details
KWin support information (5.64 KB, text/plain)
2016-03-27 06:43 UTC, Thomas Bächler
Details
KWin Support Information (6.88 KB, text/plain)
2016-06-20 06:05 UTC, Bob Wya
Details
qdbus kwin supportInformaton (6.51 KB, text/plain)
2016-07-28 22:40 UTC, Michael Butash
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gao yang 2015-01-11 02:27:34 UTC
Kde saves sessions. I closed my computer and turn it again. Before I close there are two Mozilla Firefox window in two different virtual desktop. But after I closed the window on desktop2, a unreal window remained, same as the one I closed it. It blocked me to see desktop and I cannot do any thing to it, such as alt-tab or see desktop bottom. 

Reproducible: Didn't try
Comment 1 Gao yang 2015-01-11 02:30:37 UTC
Created attachment 90335 [details]
what happens if I alt-tab
Comment 2 Thomas Lübking 2015-01-11 03:38:46 UTC
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
Comment 3 Gao yang 2015-06-16 02:46:55 UTC
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.
Comment 4 Gao yang 2015-06-16 02:56:18 UTC
like this?
http://paste.ubuntu.com/11722977/
Comment 5 Thomas Lübking 2015-06-16 07:22:09 UTC
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.
Comment 6 Gao yang 2015-06-17 06:34:09 UTC
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.
Comment 7 Gao yang 2015-06-17 06:42:58 UTC
No, this problem just happened when I enables translucency only.
Maybe this problem is related to Nvidia graph card I think.
Comment 8 Thomas Lübking 2015-06-17 08:42:40 UTC
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.
Comment 9 Gao yang 2015-06-18 03:07:41 UTC
Created attachment 93221 [details]
Settings of transparecy
Comment 10 Gao yang 2015-06-18 03:13:56 UTC
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.
Comment 11 Thomas Lübking 2015-06-18 11:28:10 UTC
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?
Comment 12 Gao yang 2015-06-19 09:51:01 UTC
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.
Comment 13 Gao yang 2015-06-19 09:51:49 UTC
Created attachment 93233 [details]
This also brock the ghost window
Comment 14 Thomas Bächler 2016-03-27 06:40:55 UTC
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.
Comment 15 Thomas Bächler 2016-03-27 06:43:29 UTC
Created attachment 98109 [details]
KWin support information
Comment 16 Thomas Lübking 2016-06-04 21:28:42 UTC
*** Bug 363923 has been marked as a duplicate of this bug. ***
Comment 17 Thomas Lübking 2016-06-04 21:29:42 UTC
*** Bug 349020 has been marked as a duplicate of this bug. ***
Comment 18 Thomas Lübking 2016-06-05 15:44:03 UTC
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)
Comment 19 Bob Wya 2016-06-20 06:05:47 UTC
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.
Comment 20 Alassane 2016-07-24 16:26:48 UTC
I have the same issue with both an intel card and and AMD card
Comment 21 Michael Butash 2016-07-28 22:39:05 UTC
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.
Comment 22 Michael Butash 2016-07-28 22:40:21 UTC
Created attachment 100362 [details]
qdbus kwin supportInformaton
Comment 23 Martin Flöser 2016-10-28 11:08:14 UTC
*** Bug 369340 has been marked as a duplicate of this bug. ***
Comment 24 Martin Flöser 2016-10-28 12:39:09 UTC
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
Comment 25 Martin Flöser 2016-10-28 12:47:03 UTC
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.
Comment 26 Martin Flöser 2016-10-28 14:25:11 UTC
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