please attach the output of "qdbus org.kde.kwin /KWin supportInformation" (with gl compositing running) as well as "glxinfo -l" and "xrandr -q"
Thanks

5 EUR on NVIDIA :-)

Seeing the video, please also provide the output of "xprop" (the cursor turns into a cross to allow you to pick the window) on the window when it's black.

Hi, the cursor has turned to cross because the window wasn't maximized, so it is ok.

The outputs:
qdbus: http://paste.kde.org/p8f0da506/00983313/
glxinfo: http://paste.kde.org/p83a675d1/90097801/
xrandr: http://paste.kde.org/pbaeea66c/09863137/
xprop: http://paste.kde.org/p072daa7b/90100261/

There are a few more bugs that appered afrer upgrade to 4.10. When I close RM window it is laggy, window disappear like a slideshow (I have enabled kwin effect for closing windows, so they become opaque).

Another much more serious problem is related to hibernate/restore. I often do not reboot my PC for 5-10 days using hibernate instead. And now often after restore I see a black screen with some small flashing parts of the desktop. This could be fixed by switching to console and restart kwin.

(In reply to comment #4)
> Hi, the cursor has turned to cross because the window wasn't maximized, 

That's not what i mean, but it's neither important - you managed to get the xprop dump ;-)

> _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ

This says the window is maximized (but on the video it seemed the window turned black when it was NOT maximized)
Is this from the "black" or the "visible" window?

> There are a few more bugs that appered afrer upgrade to 4.10. 
Please to not collect bugs. Makes triaging them hell on earth.

> When I close
> RM window it is laggy, window disappear like a slideshow (I have enabled
> kwin effect for closing windows, so they become opaque).

For now, i assume this to be the same issue (the black window means that the driver could not assign a texture - that's never a good sign)

> Another much more serious problem is related to hibernate/restore.
This is bug #322975 - From the explanations there, i fear this is the driver (but have no idea what exposes it), though restarting KWin from VT1 has been disregarded as viable option there.

Please comment this and whether toggling compositing twice "fixes" the problem as well *there* (not here)

(In reply to comment #2)
> 5 EUR on NVIDIA :-)

Qt Graphics System: raster
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL version string: 4.3.0 NVIDIA 325.15
OpenGL shading language version string: 4.30 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 325.15
GPU class: GF100
OpenGL version: 4.3
GLSL version: 4.30

Hi, it is from the visible window.

But is is not necessary that a black window could not be maximized. Just started RM, it is maximized and the content is black again. Sometimes it starts maximized but content is visible and turns black when I click the "restore" button.

xprop (maximized and black): http://paste.kde.org/pc8edc81a/13790546/

> Please to not collect bugs. Makes triaging them hell on earth.
Sure, just asked here to check if those are known problems.

I can now reproduce the bug, please take a look:
http://www.youtube.com/watch?v=8h70BCq25e0

Oops, sorry for the Russian lang,  I tried to switch application language to Eng and restart the systemsettings, but effects' names were still in Russian. Perhaps another bug :)

The effect I was playing with on the video called "Maximize", but you probably already guessed.

Hi, I can also confirm this bug:

Ubuntu: 13.10                          
Qt: 4.8.4                                                                                                                          
KDE: 4.11.3                                                                                                                        
KWin: 4.11.3 
Nvidia driver: 319.60
X-Server: 1.14.3

xprop output on a black rendered xterm window (not maximized): http://pastebin.kde.org/pn82qa0pa
glxinfo: http://pastebin.kde.org/pdh7k5gsd
xrandr: http://pastebin.kde.org/pmbndbjd2
qdbus output could not be pasted on pastebin.kde.org (triggered spam filter). I will attach it as a file.

Note: Input in the window is accepted while it is black (i.e. xterm has written characters I have typed while it was black)

When does this occur? Mostly after wakeup or after unlocking the session.
It does not happen to all of the windows (most notably xterm, but not Konsole, happens to Thunderbird, but not Chrome, Skype is affected, but not Pidgin)

Ways to work around:
- Maximize, restore the black window
- Switch off/on compositing in kwin
- Logout/Login
- Reboot

Created attachment 83556 [details]
qdbus output

*** Bug 327884 has been marked as a duplicate of this bug. ***

*** Bug 329179 has been marked as a duplicate of this bug. ***

*** Bug 329179 has been marked as a duplicate of this bug. ***

Can confirm this bug, happens for me too. 

Qt Graphics System: nativ
Compositing Type: OpenGL 2.0
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 334.21
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.4.0 NVIDIA 334.21
OpenGL shading language version string: 4.40 NVIDIA via Cg compiler
NVIDIA driver version: 334.21

Created attachment 89411 [details]
qdbus org.kde.kwin /KWin supportInformation   output

I want to confirm this bug also. 
qdbus debug output attached.
Nvidia, proprietary driver.
Bug is observed only when "Maximize" Kwin effect is turned on.
Can I somehow help to pinpoint, what exactly is broken in proprietary driver, that causes this behaviour? So we can fill a bugreport on nvidia forum or whatever they have.

This problem plagued compiz as well for a time, until nvidia took a look at GLX usage.
Their finding is here: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1072206/comments/63

Basically it boils down that two GLX pixmaps via glXCreatePixmap are created from the
same drawable, which isn't working in the nvidia driver, i.e. both pixmaps are actually used
without an intervening glXDestroyPixmap.

I've noticed this problem with plasma5, kwin 5.3.2, nvidia driver.

I have looked a bit at current kwin_x11 code (git bc45c61e), and haven't found immediately 
where that would happen.  But the whole crossFadePrevious handling (with possibly doing that
via ->texture() on previousWindowPixmap results) looks like such things might happen.
At least the Maximize effect is the only one using CrossFadePrevious.

Maybe someone knowing that code better sees quicker where the problem is.

(In reply to Michael Matz from comment #16)
> Basically it boils down that two GLX pixmaps via glXCreatePixmap are created
> from the
> same drawable, which isn't working in the nvidia driver, i.e. both pixmaps
> are actually used
> without an intervening glXDestroyPixmap.

The description in the linked bug report shouldn't happen inside KWin - also not with crossfading. The basic idea behind the cross fading is that it is for different pixmaps, in particular of different sizes. So the "while the window's pixmap hasn't changed" condition should not be hit in KWin.

Also the cross fading mechanism itself should ensure that the problem cannot be hit as it reuses the "old" pixmap till a new one is created. So if the driver fails giving us a new one, we will continue to use the old one.

Of course I don't want to throw away the possibility that there are conditions where it could be hit due to bugs. If that's the case we need a very good test case for the situation.

If in deed the cross fading mechanism is causing the problem on NVIDIA we need to turn it into a driver capability and disable it for NVIDIA - this would no longer happen for 4.11 branch, though.

Can you 
a) reproduce this somewhat reliably
b) try a patch?

ftr:
::plainResize() in geometry.cpp has a semi-uncoditional discardWindowPixmap() which is reached even if s == geom.size() what happens when at least when the decoration is re/created, ie. we actually can discard the pixmap (and take a new one) on the same drawable size.

(In reply to Thomas Lübking from comment #18)
> Can you 
> a) reproduce this somewhat reliably

Yes, I have the blackness effect almost always when maximizing a window
(with the maximize effect).  It doesn't happen always, so it is racy, but it happens perhaps 9 out
of 10 times.

> b) try a patch?

Yes.

*Not* tested in any way:
---------------------------

diff --git a/geometry.cpp b/geometry.cpp
index 9876477..8ad4820 100644
--- a/geometry.cpp
+++ b/geometry.cpp
@@ -1902,6 +1902,7 @@ void Client::setGeometry(int x, int y, int w, int h, ForceGeometry_t force)
     // Such code is wrong and should be changed to handle the case when the window is shaded,
     // for example using Client::clientSize()
 
+    QSize oldClientSize = client_size;
     if (shade_geometry_change)
         ; // nothing
     else if (isShade()) {
@@ -1970,7 +1971,8 @@ void Client::setGeometry(int x, int y, int w, int h, ForceGeometry_t force)
     // - maximize mode is changed to MaximizeRestore, when size unchanged
     //   which can happen when untabbing maximized windows
     if (resized) {
-        discardWindowPixmap();
+        if (oldClientSize != client_size)
+            discardWindowPixmap();
         emit geometryShapeChanged(this, geom_before_block);
     }
     const QRect deco_rect = visibleRect();
@@ -1990,6 +1992,7 @@ void Client::setGeometry(int x, int y, int w, int h, ForceGeometry_t force)
 void Client::plainResize(int w, int h, ForceGeometry_t force)
 {
     // this code is also duplicated in Client::setGeometry(), and it's also commented there
+    QSize oldClientSize = client_size;
     if (shade_geometry_change)
         ; // nothing
     else if (isShade()) {
@@ -2034,7 +2037,8 @@ void Client::plainResize(int w, int h, ForceGeometry_t force)
     updateWindowRules(Rules::Position|Rules::Size);
     screens()->setCurrent(this);
     workspace()->updateStackingOrder();
-    discardWindowPixmap();
+    if (oldClientSize != client_size)
+        discardWindowPixmap();
     emit geometryShapeChanged(this, geom_before_block);
     const QRect deco_rect = visibleRect();
     addLayerRepaint(deco_rect_before_block);

Tested, bad patch - don't try!
(leaves invalid textures - smells like there is a problem in this context, though)

Created attachment 93677 [details]
Less simple patch

Little more complex patch ATTEMPT, which should however not falsely stall updates (problem was pending size changes being ignored) - and print when it newly skips a pixmap discard.

So, finally came to trying patch from comment #22, on top of tag v5.3.2 of kwin.git.
The black window bug after the maximizing effect remain, but the debug message added
by the patch does not trigger.  Something else in the debug output is interesting, though.
When the buggy behaviour doesn't happen (it doesn't always when maximizing), the debug
output contains some messages ala:

kwin_core: 0x20004: Usage warning: Generic vertex attribute array 1 uses a pointer with a small value (0x0x370). Is this intended to be used as an offset into a buffer object?
kwin_core: 0x20084: Texture state usage warning: Texture 39 is base level inconsistent. Check texture size.

Once the effect is finished debug output stops.  But if the buggy behaviour happens,
i.e. if the window content becomes black during maximizing effect and remains black
when it's finished, then the "texture state usage warning" debug output keeps repeating,
even after the effect is finished.  It keeps showing up, until I maximize/restore the window
so often until the real content shows again, instead of the black one.

The texture number itself changes from occurence to occurence of the bug, but remains
the same as long as the bug is currently happening, i.e. as long as one window is in
the buggy black state.

The text of the message is an openGL error message (output via glDebugMessageCallback).

So, somewhere there is a difference in kwin behaviour between when the bug happens
(something retries to do something but never succeeds), versus when it doesn't happen.
I haven't yet figured out what "something" here is.

FWIW: the added debug message from the patch ("SKIPPED discard ...") _does_ happen when
I resize a window (if in buggy state or not) by the window decoration border.  It doesn't happen
during the maximize effect itself.

Created attachment 93755 [details]
printf debugging stuff

A patch adding some qDebugs to various interesting glX call sites, so one understand what
I'm going to talk about in the next comment.

So, I've added some qDebugs and found something hinting at the problem I think.  With the 
patch above, when constantly maximizing and restoring the same window, the output
normally looks like so:

-------------------------------
# some initial stuff, now maximizing ...
# the following is WindowPixmap id, size, clientpos, toplevel frameid
WindowPixmap::create  104857803 QSize(1920, 1174) QRect(0,22 1920x1152) 10485768
glXCreatePixmap(  104857803  ) ==  104857762
glXBindTexImageEXT  104857762
glXReleaseTexImageEXT  104857758
glXDestroyPixmap  104857758
~WindowPixmap  104857759

# now restoring
WindowPixmap::create  104857811 QSize(1000, 914) QRect(4,26 992x884) 104857681
glXCreatePixmap(  104857811  ) ==  104857804
glXBindTexImageEXT  104857804
glXReleaseTexImageEXT  104857762
glXDestroyPixmap  104857762
~WindowPixmap  104857803
-------------------------------

So, as can be expected, when maximizing a new pixmap is created for the same toplevel
window (of the larger size), then a GLX pixmap is created from that, it's bound, then drawing 
and animation takes places, and when finished the old GLX pixmap and window pixmap are destroyed (e.g. in the above when restoring the destroyed windowpixmap 104857803 is
the one from the maximization before).

Reverse happens when restoring.  So, when constantly maximizing and restoring the pattern
is easy to see: a ::create call with the large size, some pixmap creation/destroying, and
and ::create call with the smaller size, some more pixmap stuff.

Now, when the bug happens it is always the case that there are _two_ WindowPixmap::create
calls with the _same size_ but different clientpos/clientsize (i.e. only the m_contentsRect changes, not the pixmapSize).  Like in the following, it starts with the very first setup
of the pixmaps for the window in question (in normal size, and no former pixmaps), then I did 
one maximization, the bug happened, and I did one restoring and the bug went hiding (i.e.
I was lucky to exhibit the bug nicely):

---------------------------------
WindowPixmap::create  104857757 QSize(1000, 914) QRect(4,26 992x884) 104857675
glXCreatePixmap(  104857757  ) ==  104857756
glXBindTexImageEXT  104857756

# now I maximized
WindowPixmap::create  104857803 QSize(1920, 1174) QRect(4,26 1912x1144) 104857675
glXCreatePixmap(  104857803  ) ==  104857762
glXBindTexImageEXT  104857762
glXReleaseTexImageEXT  104857756
glXDestroyPixmap  104857756
~WindowPixmap  104857757
WindowPixmap::create  104857807 QSize(1920, 1174) QRect(0,22 1920x1152) 104857675
glXCreatePixmap(  104857807  ) ==  104857804
glXBindTexImageEXT  104857804
glXReleaseTexImageEXT  104857762
glXDestroyPixmap  104857762
~WindowPixmap  104857803

# after this the window content was black

# then I restored again, and I was lucky enough to see the windows content again
WindowPixmap::create  104857917 QSize(1000, 914) QRect(4,26 992x884) 104857675
glXCreatePixmap(  104857917  ) ==  104857808
glXBindTexImageEXT  104857808
glXReleaseTexImageEXT  104857804
glXDestroyPixmap  104857804
~WindowPixmap  104857807
----------------------------------------

So, to recollect, for one maximization there are two WindowPixmaps created,
both of size 1920x1174, but once for contents 4,26@1912x1144, and once at 0,22@1920x1152.

The contentRect size differences are 8x8 and the position differences are 4x4, so I guess
the difference is, that once the borders are included, and once they aren't.  It is also
always the case that when the bug happens, that the first of the two ::create calls
shows the clientPos still at the one before (with the clientSize appropriately adjusted),
and the second one has the final clientPos for the operation in question (0,22 for my
decorations when maximizing).

Now comes the guessing part: the geometry of the various data structures in kwin
is changed in several steps, e.g. first toplevel, then pixmaps, then clientRect, then removing borders when maximizing, then updating clientRect again, but no changes to the X drawable
anymore.  I also guess during this there are multiple events fired that would result in
rendering the window.  Now if such rendering would happen while the pixmaps and other
X11 drawables are already in their final state, but a clientRect adjustment would result in
another drawing request, then the newly created GLX pixmap would indeed refer to a X
pixmap that still was created from the same drawable (it does have a different index, but the
underlying drawable is the same, like in the bug report about compiz I linked); and in nvidia
the result would be like observed.

I've tried to confirm this speculation with more qDebugs in setGeometry, but haven't 
pinpointed it yet.  I have something like this in my notes:
-----------------------------
# XXXXXXXX here the problem starts:
setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
# so multiple setGeometry calls, resulting in one halfway painting:
WindowPixmap::create  109052237 QSize(1920, 1174) QRect(4,26 1912x1144) 10905197
glXCreatePixmap(  109052237  ) ==  109052228
glXBindTexImageEXT  109052228
# then more superfluous setGeometry calls ...
setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
# ... now the rest of the already started painting:
glXReleaseTexImageEXT  109052219
glXDestroyPixmap  109052219
~WindowPixmap  109052227
# Ugh, and now another painting attempt with same size:
WindowPixmap::create  109052241 QSize(1920, 1174) QRect(0,22 1920x1152) 10905197
glXCreatePixmap(  109052241  ) ==  109052238
glXBindTexImageEXT  109052238
glXReleaseTexImageEXT  109052228
glXDestroyPixmap  109052228
~WindowPixmap  109052237
----------------------------------------------

that additional output was with:

diff --git a/geometry.cpp b/geometry.cpp
index a204d64..26cd43c 100644
--- a/geometry.cpp
+++ b/geometry.cpp
@@ -1882,6 +1881,7 @@ void Client::setGeometry(int x, int y, int w, int h, ForceGeometry_t force)
             pending_geometry_update = PendingGeometryNormal;
         return;
     }
+    qDebug() << "setGeometry " << g << " for " << this;
     bool resized = (geom_before_block.size() != geom.size() || pending_geometry_update == pendingGeometryForced);
     if (resized) {
         resizeDecoration();

Thanks for the great investigation!

It's easily possible that the deco border change is the ultimate trigger (run "breeze-settings5" and check "display borders for maximized windows" in the "window decoration" page to verify this), but your debug out doesn't look that surprising :-(

NOTICE, that your last "setGeometry" call does not imply something really happens - geometry updates may still be blocked.

Here's what it looks to me:

> # XXXXXXXX here the problem starts:
> setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> # so multiple setGeometry calls, resulting in one halfway painting:
> WindowPixmap::create  109052237 QSize(1920, 1174) QRect(4,26 1912x1144) 10905197
> glXCreatePixmap(  109052237  ) ==  109052228
> glXBindTexImageEXT  109052228

One of the last setGeometry calls effectively changed the size of the decorated client window, the pixmap needs to be (re)-created.
::setGeometry() being called from various positions isn't that uncommon, therefore the entire geomerty blocking thing.

Notably see the client rect size: "QRect(4,26 1912x1144)"

> # then more superfluous setGeometry calls ...
> setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k

I assume that these are caused by the deco border resize. The entire window size does not change due to this, but the decorated client will (as the borders are removed, it gains room to grow a bit)

> # ... now the rest of the already started painting:
> glXReleaseTexImageEXT  109052219
> glXDestroyPixmap  109052219
> ~WindowPixmap  109052227

The old previous client pixmap is released, because (hopefully) the client size changed by the deco borders being removed - next we need a new pixmap and the new current becomes the previous one.

> # Ugh, and now another painting attempt with same size:
> WindowPixmap::create  109052241 QSize(1920, 1174) QRect(0,22 1920x1152) 10905197
> glXCreatePixmap(  109052241  ) ==  109052238
> glXBindTexImageEXT  109052238

There it is.
Notably see the NEW client rect size: "QRect(0,22 1920x1152)" (was 4,26 1912x1144)

The client size is (should be) irrelevant in this regard, the client texture size is the one of the redirected window _inside_ the decorated client.

Here it perhaps gets interesting:

> glXReleaseTexImageEXT  109052228
> glXDestroyPixmap  109052228
> ~WindowPixmap  109052237

The previous pixmap is destroyed - if you slow down the maximization effect (animation speed in "kcmshell5 kwincompositing"), you should notice that this happens NOT before the crossfading is supposed to have ended.

(In reply to Thomas Lübking from comment #28)
> It's easily possible that the deco border change is the ultimate trigger
> (run "breeze-settings5" and check "display borders for maximized windows" in
> the "window decoration" page to verify this),

The way borders are enabled/disabled when restoring/maximizing is one or the trigger
probably.  Because I can't reproduce the problem with the breeze windows deco at all, only
with Plastik (no matter the "display borders" setting for breeze).

> NOTICE, that your last "setGeometry" call does not imply something really
> happens - geometry updates may still be blocked.

Yes, I know, but whenever there's a WindowPixmap::create() call after a setGeometry,
that hints at the fact that for that setGeometry call the updates weren't blocked anymore.

Let me try to point to what I think the problem with the GLX pixmaps is (maybe we're saying
the same thing already, but just to clear up my own mind :) ):

> > # XXXXXXXX here the problem starts:
> > setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> > setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> > # so multiple setGeometry calls, resulting in one halfway painting:
> > WindowPixmap::create  109052237 QSize(1920, 1174) QRect(4,26 1912x1144) 10905197
> > glXCreatePixmap(  109052237  ) ==  109052228
> > glXBindTexImageEXT  109052228

(Reducing the IDs to the last three digits)  So one of these setGeometry calls resulted
in repainting (so the geom changes weren't blocked), and hence
we created a GLX pixmap 228 from a drawable 237 (for toplevel 197).
At this point (from before the resize) we still have a drawable 227 and GLX pixmap 219
(for different sizes, so it's really a different drawable and pixmap).

> > # then more superfluous setGeometry calls ...
> > setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> > setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> > setGeometry  QRect(0,0 1920x1174)  for  'ID: 58720413 ;WMCLASS: "konqueror" : "k
> 
> I assume that these are caused by the deco border resize. The entire window
> size does not change due to this, but the decorated client will (as the
> borders are removed, it gains room to grow a bit)

Right.  So this will change the client size, but not the size (or other attributes)
of the underlying drawable.  Then what follows is:

In one thread of program flow the GLX and windowpixmap handling continues,
we just created 228 and 237 above and now we continue on and destroy the old
pixmap (219) and drawable (227):

> > # ... now the rest of the already started painting:
> > glXReleaseTexImageEXT  109052219
> > glXDestroyPixmap  109052219
> > ~WindowPixmap  109052227

Note how we still have the 228 and 237 objects internally referring to the toplevel.
One of the above later setGeometry calls (or something else) activates the whole
create windowpixmap and GLX pixmap business again, now with changed (and final)
client rect size, but same drawable size:

> > # Ugh, and now another painting attempt with same size:
> > WindowPixmap::create  109052241 QSize(1920, 1174) QRect(0,22 1920x1152) 10905197
> > glXCreatePixmap(  109052241  ) ==  109052238
> > glXBindTexImageEXT  109052238

So we now created another windowpixmap 241 (for toplevel 197), referring to the same
underlying window with unchanged properties from when 237 was created above.
From that we generate GLX pixmap 238, et voila, we now have two GLX pixmaps
referring (indirectly via the windowpixmaps 237 and 241) to the same drawable
(it is the same because no attributes changed between creating one windowpixmap and the
other).

From the description of the NVIDIA guy in the compiz bug, this creation of the second
GLX pixmap is already the one that's breaking.  Even though we destroy the older pixmap
and GLX pixmap right away:

> > glXReleaseTexImageEXT  109052228
> > glXDestroyPixmap  109052228
> > ~WindowPixmap  109052237

... the newer GLX pixmap (238) is still the invalidly constructed one, and the one we continue
to use to do the drawing.

Perhaps this can be rectified by first destroying the GLX pixmap and only then creating
a new one, but this probably isn't possible in the current design with the previous
pixmap and current pixmap.

Alternatively the situation could be detected that if the drawable didn't really change
from when the GLX pixmap was created then no new one would be generated.

Created attachment 93837 [details]
Adjusted not so simple patch

> only with Plastik (no matter the "display borders" setting for breeze).

Ahhhhhh... easily reproducable.
Please try the updated patch.

(In reply to Thomas Lübking from comment #30)
> > only with Plastik (no matter the "display borders" setting for breeze).
> 
> Ahhhhhh... easily reproducable.
> Please try the updated patch.

Hah!  I now do see some 'SKIPPED discard' messages when I continuously maximize/restore
windows, and no further multiple WindowPixmap::create calls with the same QSize (and only
different client QRect) in a row.  The effects of that (i.e. the black contents) are also gone
(incidentally showing that it's indeed the multiple GLX pixmaps from same drawable that
cause this effect).

Excellent, thanks.

Ok, many thanks for your testing and debugging efforts =)

There'll be something more to this, the significant (in this context, I believe) difference between aurorae (what also powers plastik) and breeze is that former utilizes a GL context of its own, so we have a pixmap update for a drawable that is itself a GL context - an I could assume that this might lack a sync between the context switches (but it's only a guess)

(In reply to Thomas Lübking from comment #32)
> Ok, many thanks for your testing and debugging efforts =)
> 
> There'll be something more to this, the significant (in this context, I
> believe) difference between aurorae (what also powers plastik) and breeze is
> that former utilizes a GL context of its own,

Yeah, right, I noticed this later as well, when reading code (trying to find out why
aurorae needs 70 to 100 MB more memory than breeze in my situation ;-) At least part of
it is because of the QOpenGLFramebufferObject objects in the decoration).  As it seems
mostly to be used for drawing the shadow, and breeze can do the same without (using a much
smaller image) I wonder if that aurorae code isn't meanwhile obsolete from pre-compositing
times.

> so we have a pixmap update for
> a drawable that is itself a GL context - an I could assume that this might
> lack a sync between the context switches (but it's only a guess)

Yeah, possibly, but I think the general idea of not discarding a pixmap if the attributes
haven't changed, as in your patch, is a good thing nonetheless.

Git commit eb71b47db430bd04b859e49e0415192ae7114a25 by Thomas Lübking.
Committed on 14/08/2015 at 23:34.
Pushed by luebking into branch 'Plasma/5.4'.

only discard pixmaps when the XCB Window resized

Causes invalid textures on the nvidia blob
when referencing textures for crossfading
eg. during maximization
REVIEW: 124591
FIXED-IN: 5.4

M  +6    -2    geometry.cpp

http://commits.kde.org/kwin/eb71b47db430bd04b859e49e0415192ae7114a25

*** Bug 347425 has been marked as a duplicate of this bug. ***

*** Bug 347638 has been marked as a duplicate of this bug. ***