Created attachment 69716 [details]
Screenshot showing the issue

As you are already on Mesa 8: did it also occur with Mesa 7.x?

Could you please try using the raster system and could you please try running KWin from Konsole and watch the debug output when using Alt+Tab. It looks a little bit like the QML file is not loaded correctly.

I bet on shaders ;-)
"kcmshell4 kwincompositing", 3rd tab - is scale method set to "accurate"?
Try "smooth" instead, disable blurring in the second tab and in doubt even disable OpenGL 2 shaders (3rd tab)

I f the issue's gone, check whether what you can re-enable w/o breaking it.

In data martedì 20 marzo 2012 15:51:22, hai scritto:

> I bet on shaders ;-)
> "kcmshell4 kwincompositing", 3rd tab - is scale method set to "accurate"?

Setting from accurate to smooth by itself had no effect (I tried it suspecting 
that).

> Try "smooth" instead, disable blurring in the second tab and in doubt even
> disable OpenGL 2 shaders (3rd tab)

I will try to test it tonight. Interestingly, it's hardware-dependent because 
with the same driver (radeon) but a different card I do not see this.
I've seen reports of it breaking on Intel hardware too, though.

(In reply to comment #3)
> I bet on shaders ;-)
I bet against as comment #0 mentions that it works correctly with GLES.

(In reply to comment #4)
> I will try to test it tonight. Interestingly, it's hardware-dependent
> because 
> with the same driver (radeon) but a different card I do not see this.
> I've seen reports of it breaking on Intel hardware too, though.
do they all have the same driver version or are some of them still on Mesa 7.x?

I see the same as Luca indicated. I am having an intel graphics and am running the same software versions as Luca. Mesa with me is 8.0.1

can you check whether the "thumnail aside" effect causes the same?

@Martin
i didn't mean the shaders are broken, but the shader usage might impact the additional usage (and libGL ain't libGLES ;-)
I think there's a similar bug, and i think not using glsl resolved it for the user, but i'm not entirely sure...

I'm not sure it is related, but the same effect (black window) is observed 
when doing quick tiling, to be precise the "drag to top to maximize".

the original window or the "outline" (ie. the "transparent" frame to hint the coming window size)?
in case of latter: tried to change the plasma theme?
(do you in this regard "outline" the selected window, "kcmshell4 kwintabbox")

In data martedì 20 marzo 2012 22:17:41, hai scritto:

> the original window or the "outline" (ie. the "transparent" frame to hint
> the coming window size)?

The outline. I just checked. I mean, the black area is as big as the to-be-
maximized window.

> in case of latter: tried to change the plasma theme?

Nope, haven't tried that yet. Will try that tomorrow. 

> (do you in this regard "outline" the selected window, "kcmshell4
> kwintabbox")

If outline is unchecked, I do not experience the issue.

I have the exact same problem on i915, kde 4.9 beta, mesa 8.0.3.

Is the graphicssystem set to "raster" and if not, does setting it to "raster" fix it?
("kcmshell4 kwincompositing", 3rd tab - only in 4.9)

Yup, that fixes all the problems I had (had some other corruption as well) and preserves all the effects such as blur. Nice. So that's a workaround while "native" still is broken. XRender also works fine, by the way, though it cannot do blur.

In data sabato 09 giugno 2012 12:32:36, hai scritto:

> Is the graphicssystem set to "raster" and if not, does setting it to
> "raster" fix it?

After setting to raster, I no longer see the issue.

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

in case one of you happens to compile KWin fomr sources and are willing to try - there're patch suggestions in the dupe, comments #16 / #19 and as a broad sword #23

None of them however has seemed to work for the reporter - but not seleting the target type worked at least here (intel)

Ok, i found the source of the (local, intel) issue.
Reason is that
a) the i915/i945 has 
Texture NPOT support:                   limited
BUT
GLTexture::NPOTTextureSupported() == true
because
GLTexturePrivate::initStatic()
sNPOTTextureSupported = hasGLExtension("GL_ARB_texture_non_power_of_two");
as "glxinfo | grep non_power"
    GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object,

So the GPU claims NPOT support, kwin glplatform says "limited" (the init value?!) and that causes some kind of conflict.

-> I tried to free NPOT by setting "m_limitedNPOT = false;" (for all intel drivers) but that doesn't resolve the bug, so at least for this condition (not sure about the ati case in bug #301068) the solution seems to be to ask GLPlatform about whether we can use NPOT or not.

Created attachment 71688 [details]
patch attempt using glplatform NPOT

the attached patch works for me but i've no idea whether it's a general solution or only covers a particular (sub)issue.

If you can, please try and report - thanks.

That patch does not appear to work for me. I set it back to "native" but the issues reappeared just like before.

when you start kwin from konsole or call "qdbus org.kde.kwin /KWin supportInformation" - what does it say about NPOT (and direct rendering)?

In data domenica 10 giugno 2012 07:22:04, hai scritto:

> supportInformation" - what does it say about NPOT (and direct rendering)?

Texture NPOT support:  yes
Direct rendering: yes

@Luca
Thanks, but i need the information from Sven-Hendrik (while the patch should have no effect on your GPU - there must be sth. else)

Direct rendering: yes
Requires strict binding: yes
GLSL shaders:  yes
Texture NPOT support:  yes
OpenGL 2 Shaders are used

on an i915??
While it corresponds with the glxinfo output, it does not match the determination of KWin GLPLatform (on Mesa 8.0._2_, though)
Nor is GLSL enabled (but that might be a past beta patch)

Can you please
a) disable GLSL ("OpenGL 2 shaders") and
b) patch kwin/libkwineffects/kwinglplatform.cpp to at about line 746 (at the end of void GLPlatform::detect()) say "m_limitedGLSL = true;"

Just to be sure: you're running kwin (ie. the GLX variant) and not kwin_gles?!

Thomas, can you talk to me in irc (svenstaro@irc.freenode.net)? Perhaps quicker feedback from boths sides will get this resolved more quickly.

(In reply to comment #25)
> Thomas, can you talk to me in irc (svenstaro@irc.freenode.net)? Perhaps
> quicker feedback from boths sides will get this resolved more quickly.

I doubt so (i've virtually no IRC experience, just entered freenode #irc but there's no svenstaro - see, i don't even know how to contact you in that medium =)

I'll run an update on the intel box to get mesa 8.0.3 and see what happens, but right now i'm under the impression that at least you observe this for failing attempts to create NPOT textures, because that throws GL errors when i try here.

Just type "/msg svenstaro hi" or something like that :)

Same problem for me, the patch, applied on today's trunk, doesn't fix the issue.

If "Use OpenGL2 Shaders" option is disabled the box from black becomes white.

I have black box also with Present windows (Ctrl+F9) but, interestingly enoght, they are for the icon and the title of the windows and not for the content (see attachment)


OpenGL version string: 3.0 Mesa 8.0.2
Driver: Intel
GPU class: SandyBridge
OpenGL version: 3.0
Mesa version: 8.0.2
Direct rendering: yes
GLSL shaders:  yes
Texture NPOT support:  yes
OpenGL 2 Shaders are used

skip ALL attached patches and use this one:
https://git.reviewboard.kde.org/r/105249/

All problem fixed with patch in reviewboard #105249

Alt+Tab works as expected and so does Present Windows too. Thanks!

I just notice that running kwin from konsole (kwin --replace after git apply) there were theese messages, (anyway already present with unpatched version):

ImageProvider supports Pixmap type but has not implemented requestPixmap()
file:///home/kde/main/share/apps/kwin/tabbox/thumbnails/contents/ui/main.qml:135:9: QML Image: Failed to get image from provider: image://client/-1/-59332255-0

Git commit 6147b92912ba771dd7984e37ebaf02549e55400b by Thomas Lübking.
Committed on 14/06/2012 at 01:23.
Pushed by luebking into branch 'master'.

remove (broken) mimpmap support check, disable use of mipmaps and align texture filter
FIXED-IN: 4.9
REVIEW: 105249

M  +2    -2    kwin/libkwineffects/kwingltexture.cpp
M  +4    -10   kwin/scene_opengl_glx.cpp

http://commits.kde.org/kde-workspace/6147b92912ba771dd7984e37ebaf02549e55400b

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

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

This issue seems to be back as a regression in 4.9.90. When I have the Outline effect enabled, I get plain white boxes when either dragging windows to the screen edges to maximize or tile them or when using the "Thumbnails" tabbox effect".
It happens with both render modes: Native and Raster.

Using Nouveau from kernel 3.6.6, xf86-video-nouveau-1.0.1 and mesa-8.0.4.

It's rather unlikely the same issue (also unlikely the MSAA thing, because of mesa 8)

> xf86-video-nouveau-1.0.1
Notice that the nouveau driver is not considered end-user ready for OpenGL acceleration

please at least provide the output of
   glxinfo
and
   qdbus org.kde.kwin /KWin supportInformation

if possible, please check the behavior with the nvidia blob as well.

Created attachment 75682 [details]
glxinfo output for reopened issue

(I have the same issue (white box in tab switch and tiling to screen edge) with Intel Sandybridge integrated graphics with current trunk.

OpenGL vendor string:                   Intel Open Source Technology Center
OpenGL renderer string:                 Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL version string:                  3.0 Mesa 9.0
OpenGL shading language version string: 1.30
Driver:                                 Intel
GPU class:                              SandyBridge
OpenGL version:                         3.0
GLSL version:                           1.30
Mesa version:                           9.0
X server version:                       1.13
Linux kernel version:                   3.5
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no

Created attachment 75683 [details]
KWin support information for reopened issue

Of course. I have attached both as files to this report.

I can't say if the issue is really the same. For me it just looks like this. My system was affected by the original bug as well and it looked pretty much the same. Then in the final 4.9 releases the issue was fixed and everything worked fine (also with Nouveau).
Now in 4.10b2 I get white boxes again.

Please deactivate blur & OpenGl 2.0 shaders. Check what happens.
In case the problem remains, deactivate all effects (but "outline") and check again.

If this still happens, try the xrender backend - if the problem remains there as well, try switching the plasma theme.

"Current trunk" means "today master"?

Yes, today master as in rev. 316b2dc

First, my own fault: the issue is present only if "Enable color correction (experimental)" is checked. But I find that out only after bisect..


In fact with git bisect I've reduced the cause to this range of commits:
  BAD ecc93b8	
  LAST GOOD 64e37dccea0074fc65188f789bdfb193b0dfa7d8
that are the set for color corrections.

the commits in between I couldn't try because they gave me a black screen (except for cursor)
due to KWin::checkGLError: GL error ( setupCCTexture ):  "GL_INVALID_VALUE"

(As a side note to get older commits compiling I had to backport FindFreetype.cmake from old kdelibs)

So, definitely, this is a different bug from the older one.  I suppose it's bettert to create a new report for this issue. Should I?

(sorry for the double mail)

Thanks for bisecting.

The color correction commits are quite a mess, reasonable bisecting there might be problematic.

I'll open a bug and check what's going on there.

Ooc: was color correction activated by default for you?
Fyi: unless you don't possess a wide gamut display (and pot. even if so, but the major clients don't support the Oyranos infrastructure), the color correction is likely to cause you more bad then good (and has performance costs for sure)

Color correction was rightly disabled by default; I just turned it on today just for curiosity, and notice the effect I just read about, being in CC on this report.

Thanks for the fyi :)

Yeah, you're right. The problem only occurs with Outline effect AND 
color correction enabled.
Color correction was enabled here since I actually have a wide gamut 
display, but I turned it off for now until it's stable enough to be 
used. I'm using a monitor profile with calibration data and color 
correction for the UI would have been a nice thing to prevent 
over-saturated colors in the GUI, but the white boxes are a bigger 
issue than that.