| Summary: | Black boxes shown when using alt-tab switcher with thumbnails | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Luca Beltrame <lbeltrame> |
| Component: | tabbox | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dariocambie, hdhoang, kde, manisandro, svenstaro, tittiatcoke |
| Priority: | NOR | Keywords: | regression |
| Version: | 4.9.90 (Beta 2) | Flags: | mgraesslin:
ReviewRequest+
|
| Target Milestone: | 4.9 RC 1 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/105241/ | ||
| Latest Commit: | http://commits.kde.org/kde-workspace/6147b92912ba771dd7984e37ebaf02549e55400b | Version Fixed In: | 4.9 |
| Sentry Crash Report: | |||
| Attachments: |
Output of supporting information from KWin
Screenshot showing the issue patch attempt using glplatform NPOT glxinfo output for reopened issue KWin support information for reopened issue |
||
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. |
Created attachment 69715 [details] Output of supporting information from KWin Setup: ATI Radeon 4850 with FOSS drivers. When setting the alt-tab switcher to use thumbnails, the current highlighted window is shown as a black square (see screenshot). The problem does not occur if OpenGL ES is used. Steps to reproduce: 1. Set tab switcher to use thumbnails (System Settings > Window behavior > "Layout Based Switcher" > "Thumbnails" 2. Alt-tab between windows Expected results: window thumbnails are shown for all the windows Actual results: the currently highlighted window is a black square Screenshot and supporting information will be attached to this report.