Bug 325939

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