Bug 325939

Summary: 'Desktop Switch On-Screen Display' Goes Blank/Black with adding transition
Product: [Plasma] kwin Reporter: KdeBugs <7d91fffe>
Component: scene-openglAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 4.11.2   
Target Milestone: ---   
Platform: Archlinux   
OS: Linux   
Latest Commit: Version Fixed In: 4.11.3
Attachments: Desktop Switch On-Screen Display - Screen shot

Description KdeBugs 2013-10-12 19:00:37 UTC
I'm running Arch x64 that I just installed this past week with a KDE Full Installation.

I added the Pager widget to the taskbar, and in the Pager settings I checked to enable the 'Desktop Switch On-Screen Display' and the 'Show desktop layout indicators' is unchecked, then for the shortcuts, 'Switch to Next Desktop' & 'Switch to Previous Desktop' I added 'Ctrl+Alt+Right' & 'Ctrl+Alt+Left'.

Then I noticed when moving back and forth across the desktop with either the shortcut keys, or placing my mouse over the pager and using the mousewheel, as soon as the Desktop Switch On-Screen Display dissapeared, if at that exact moment I used the keyboard or the mouse to move again, this time the Desktop Switch On-Screen Display would appear blank, black in color.

I really rely on this nice function to help show me which desktop I'm on, and I do a lot of fast moving around at times, so it's really anonying this goes blank if you try to move the second it leaves the screen. Typically I have to wait a few seconds after it's gone to move if I want to see it.

After playing with KDE I realized this is due to the 'Fade' effect being enabled, as soon as I disable it the problem goes away and never appears again.

Please see the attached screen shot pager_switcher.jpeg

I hope this issue can be fixed soon...

Please see this bug report somone submitted that I commented on, I have a flcker as it relates to the Popup that appears for each of the 'System Settings', also because of 'Fade'

https://bugs.kde.org/show_bug.cgi?id=316269#c8

THANKS

Reproducible: Always

Steps to Reproduce:
1.  in the Pager settings check to enable the 'Desktop Switch On-Screen Display'

2. Uncheck 'Show desktop layout indicators'

3. Create keyboard shortcut keys for 'Switch to Next Desktop' & 'Switch to Previous Desktop' and use either the shortcut keys, or use a mouse scroll wheel to move back and forth.

4. As soon as the 'Desktop Switch On-Screen Display' dissappears move again, try to move the second it dissapears and hopefully it will turn black.

5. I'm using the default settings for the Effects in KDE 4.11.2, nothing has been changed.
Actual Results:  
'Desktop Switch On-Screen Display' turns black when moving to fast...

Expected Results:  
'Desktop Switch On-Screen Display' should be visable at all times when moving...

'Desktop Switch On-Screen Display' should be visable at all times when moving...
Comment 1 KdeBugs 2013-10-12 19:02:26 UTC
Created attachment 82806 [details]
Desktop Switch On-Screen Display - Screen shot
Comment 2 Thomas Lübking 2013-10-12 22:32:22 UTC
This has nothing to do with the fade effect in particular, any "show" transition would causes this and i bet you will not be able to trigger this on the XRender backend.

Likely falls into the categories of bug #319184 and i guess it's because Qt.X11BypassWindowManagerHint or PlasmaCore.Dialog

I get animations for a popup AND a normal window here.
Could turn out the window is added twice (and then the effectwindow/scenewindow QHash mapping)
Comment 3 KdeBugs 2013-10-13 00:22:09 UTC
Can you please explain how this can be tested with this 'show' transition and the XRender backend?

I'm a Geek but it doesn't mean I know everything, in the future please explain how someone can go about testing, when you give them replies, I have no idea how to go about anything you just mentioned...

THANKS
Comment 4 KdeBugs 2013-10-13 00:32:18 UTC
(In reply to comment #3)
> Can you please explain how this can be tested with this 'show' transition
> and the XRender backend?
> 
> I'm a Geek but it doesn't mean I know everything, in the future please
> explain how someone can go about testing, when you give them replies, I have
> no idea how to go about anything you just mentioned...
> 
> THANKS

Sorry I didn't mean that to sound rude either, just not sure how to do what you are suggesting...

THANKS
Comment 5 Thomas Lübking 2013-10-13 08:18:18 UTC
You don't really have to test this, but in "kcmshell4 kwincompositing", 3rd tab you can switch the compositor (OpenGL -> XRender)
To test other animations you'd have to manipulate/write the code.

There're other problems with this item as well (bug #316372) and i guess it's ultimately the same source.
Comment 6 Thomas Lübking 2013-10-13 17:35:44 UTC
dev note: the reason seems that the window performs two configureNotifications right before it's unmapped.

If the window re-maps while the deleted is still arount, the windowPixmap is *always* discarded then.

Not discarding the pixmap on configureNotify events prevents the balck window (but is of course no solution)
Comment 7 Thomas Lübking 2013-10-14 17:25:44 UTC
The windows have different texture enums.
However, activating the indicator and causing the black/discarded state *drastically* raises odds to get all windows being "black" (invalid textures, i guess) - i have never seen that before but now it happes after some "broken" VD switches.
Comment 8 Thomas Lübking 2013-10-14 20:36:31 UTC
Interesting. "Fix":

diff --git a/kwin/toplevel.cpp b/kwin/toplevel.cpp
index 1267823..d7ff940 100644
--- a/kwin/toplevel.cpp
+++ b/kwin/toplevel.cpp
@@ -111,8 +111,8 @@ void Toplevel::copyToDeleted(Toplevel* c)
     vis = c->vis;
     bit_depth = c->bit_depth;
     info = c->info;
-    client = c->client;
-    frame = c->frame;
+    client = 0; //c->client;
+    frame = 0; //c->frame;
     ready_for_painting = c->ready_for_painting;
     damage_handle = None;
     damage_region = c->damage_region;
Comment 9 Thomas Lübking 2013-10-14 22:32:12 UTC
Zlich....

AND THE WINNER IS.... drumroll.....



diff --git a/kwin/scene.cpp b/kwin/scene.cpp
index 5982da7..3044d0f 100644
--- a/kwin/scene.cpp
+++ b/kwin/scene.cpp
@@ -852,7 +852,7 @@ WindowPixmap::~WindowPixmap()
 
 void WindowPixmap::create()
 {
-    if (isValid()) {
+    if (isValid() || toplevel()->isDeleted()) {
         return;
     }
     XServerGrabber grabber();

We try to create a window pixmap from a deleted window - what apparently slightly confuses the server.
This fits the blackwindow issue on the konqueror popup as well (which did show-hide-show)
Comment 10 KdeBugs 2013-10-14 23:03:15 UTC
So this is going to need to be patched in a next release?

Thanks
Comment 11 Martin Flöser 2013-10-15 05:40:57 UTC
ShipIt(TM)
Comment 12 Martin Flöser 2013-10-15 15:44:19 UTC
> Interesting. "Fix":
makes sense to me. I never really understood why the client and frame are 
copied into the deleted. After all they are "gone" at the point when copied 
into the deleted.
> 
> diff --git a/kwin/toplevel.cpp b/kwin/toplevel.cpp
> index 1267823..d7ff940 100644
> --- a/kwin/toplevel.cpp
> +++ b/kwin/toplevel.cpp
> @@ -111,8 +111,8 @@ void Toplevel::copyToDeleted(Toplevel* c)
>      vis = c->vis;
>      bit_depth = c->bit_depth;
>      info = c->info;
> -    client = c->client;
> -    frame = c->frame;
> +    client = 0; //c->client;
> +    frame = 0; //c->frame;
XCB_WINDOW_NONE ;-)
Comment 13 Thomas Lübking 2013-10-15 16:15:39 UTC
(In reply to comment #12)
> > Interesting. "Fix":
> makes sense to me.
Yeah, no ;-)

At least client is required (used by effects to compare deleted with former active windows etc.)
Keeping frame around did not seem to be absolutely required, but i don't like the idea to have a couple of Toplevel windows with the same frame ID either.

(And for Client rather than unmanaged it may be important to keep stacking, didn't try)

Since the actual bug is that we attempt to create window pixmaps for Deleted (could actually happen with obtaining shadow etc. as well, should result in an X11 error at best) I'd prefer to fix that and keep the knowledge about the window.

> XCB_WINDOW_NONE ;-)
sooooo maaaaany chaaaaars =)
(I was just recording debug progress, not meant to be a serious fix because of above anyway)
Comment 14 Martin Flöser 2013-10-15 17:55:49 UTC
> At least client is required (used by effects to compare deleted with former
> active windows etc.)
do you have an example of an effect which does such comparisons based on window 
Id?
Comment 15 Thomas Lübking 2013-10-15 18:18:42 UTC
No, but SlidingPopups already fails to read its property (i had blindy guessed it would do a comparism)
We'd at least have to emit windowClosed before passing the data to the deleted.
Comment 16 Martin Flöser 2013-10-15 18:26:38 UTC
> We'd at least have to emit windowClosed before passing the data to the
> deleted.
and also before the window gets destroyed which we can only ensure if the 
window follows the close protocol.
Comment 17 Thomas Lübking 2013-10-15 19:09:12 UTC
(In reply to comment #16)
> and also before the window gets destroyed which we can only ensure if the 
> window follows the close protocol.

Yes, "pkill -9 yakuake" prevents the SlidingPopup effect - it only works for unmapping, not destruction atm.
Comment 18 KdeBugs 2013-10-16 21:16:29 UTC
I see this has been confirmed, but I did not get a reply from my last comment, so I'm assuming this is something being fixed by the KDE team?
Comment 19 Thomas Lübking 2013-10-16 21:25:48 UTC
I'm really unsure what you wanted to hear.

The bug is in and the patch applies to the compositor core; you can apply it yourself, but you must recompile the patched KWin sources.

Otherwise it will just show up in 4.10.3 when your distro ships it.
Comment 20 KdeBugs 2013-10-17 21:57:59 UTC
Well I just wanted someone to reply to me is all, which no one did to let me know what was going on., started making me feel left out of the conversation... :(

Arch uses 4.11x and I thought 4.11x was the latest stable version?
Comment 21 Thomas Lübking 2013-10-17 23:23:10 UTC
Arch currently ships the first compilation of KDE 4.11.2 in the "extra" repo:
https://www.archlinux.org/packages/extra/i686/kdebase-workspace/

KDE 4.11.3 will be released: Mi 6. Nov 00:59:00 CET 2013
Arch will usually have it a week later or so.
Comment 22 Thomas Lübking 2013-10-20 18:02:25 UTC
Git commit a1507b23374c798053ce97cb9e6e5b454f590e6e by Thomas Lübking.
Committed on 14/10/2013 at 22:43.
Pushed by luebking into branch 'KDE/4.11'.

do not create window pixmap for Deleted windows

related black window issues
FIXED-IN: 4.11.3

M  +1    -1    kwin/scene.cpp

http://commits.kde.org/kde-workspace/a1507b23374c798053ce97cb9e6e5b454f590e6e