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...
Created attachment 82806 [details] Desktop Switch On-Screen Display - Screen shot
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)
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
(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
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.
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)
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.
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;
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)
So this is going to need to be patched in a next release? Thanks
ShipIt(TM)
> 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 ;-)
(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)
> 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?
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.
> 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.
(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.
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?
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.
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?
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.
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