Hello, Task switcher and Task manager do not show window thumbnail. I only get a black rectangle that reproduces the window geometry. Reproducible: Always Steps to Reproduce: 1.Let the mouse over a task manager entry. 2.wait for tooltip Actual Results: 3.tooltip does not show window contents but a black rectangle Expected Results: 3.window thumbnail is displayed. If this is a bug for all and not only reproduced in my system, please change the default task switches visualization to "informative" or something like it.
Martin, please process this as you see fit ...
A few questions: * which git snapshot (plasma-framework repo) are you running? * is compositing in KWin working? * does a restart of plasma-shell improve the situation?
* which git snapshot (plasma-framework repo) are you running? I'm using OpenSUSE OBS packages. I'm not sure how to get the exactly git snapshot but it is constantly updated. The rpm version is: plasma-framework-4.99.0~20140502~944c154-44.1.x86_64 * is compositing in KWin working? It wasn't (I don't remeber to disable it) but now it is running. However, the problem is still present. I'm using opengl 3.1 and "thumbnails for shown windows". However, I tried some combinations with 2.1 and xrender and also changes to thumbnails config. * does a restart of plasma-shell improve the situation? No. Some more info: I'm using multimonitor setup: Screen 0: minimum 8 x 8, current 2704 x 1280, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) DVI-I-1 connected 1680x1050+1024+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.9*+ 60.0 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 800x600 75.0 72.2 60.3 56.2 640x480 75.0 72.8 59.9 DP-0 connected 1024x1280+0+0 left (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 800x600 75.0 72.2 60.3 56.2 640x480 75.0 72.8 59.9 DP-1 disconnected (normal left inverted right x axis y axis) And Nvidia prop nvidia-glG03-331.49-29.1.x86_64
Binary nvidia here (334.16), compositing active and working, restarting plasma-shell does not help. Note that thumbs are working properly with kwin4.
> Note that thumbs are working properly with kwin4. ...and plasma1, that is. In combination with plasma-shell, they do not work either.
Some additional info: After plasma-shell is started (kwin5), first time I hover over taskabar I get this: plasma_shell(18826) QSGRenderContext::initialize: QSGContext::initialize: stencil buffer support missing, expect rendering errors ...after I open another application and however over the new taskbar entry, I get this: plasma_shell(18826) QXcbConnection::handleXcbError: QXcbConnection: XCB error: 2 (BadValue), sequence: 9535, resource id: 25165830, major code: 142 (Unknown), minor code: 3 plasma_shell(18826) QXcbConnection::handleXcbError: QXcbConnection: XCB error: 151 (Unknown), sequence: 9536, resource id: 25165830, major code: 143 (Unknown), minor code: 2 Lastly, each time I hover over an item (and get the black rectangle), this is printed in konsole: plasma_shell(18826) Plasma::WindowThumbnail::resolveGLXFunctions: Have texture from pixmap Note that everything is today's build.
> Note that thumbs are working properly with kwin4. what do you mean by that? If you use kwin4 those window thumbnails are shown or do you mean they are shown in a Plasma 1 session?
> ...and plasma1, that is. In combination with plasma-shell, they do not work > either. ok, that's to be expected. Plasma1/kwin4 use a different architecture
*** Bug 334375 has been marked as a duplicate of this bug. ***
consider it as fixed: I'm able to reproduce on my old MacBook with an NVIDIA. It'll take time to setup a build env, though.
problem is investigated and fully understood. Explanation: A window is either RGB or RGBA. From what we can see is that an RGBA window (e.g. Konsole) doesn't result in any problems. The black window is only shown for RGB windows. As the RGBA windows work correctly we can derive that Qt renders with blending enabled. This results in the problem for RGB windows. From the fragment shader not only the rgb values are accessed, but also the (not existing) alpha value. The value for this channel is always 0 for NVIDIA drivers. This is something we already experienced in KWin in the past. With other drivers the value is set to 1. This highly influences the blending. The typical blend function multiplies the rgb value with the alpha value. Thus with NVIDIA the color channels are multiplied by 0 resulting in all channels being 0. An rgb value of (0, 0, 0) is obviously black. So that's where our black windows come from. On the other hand in KWin this works just fine. We used to have special code in the shader to handle the situation but that got removed, because it was no longer needed. I assumed that this meant that NVIDIA fixed the problem. This is not the case though and I had to investigate why this works in KWin. KWin doesn't use blending when rendering an RGB window. If the opacity is manually changed, the glBlendFunc is adjusted to use a value set from API site. Thus the non existing alpha is overwritten from the API site. I have now an idea on how to fix this and will investigate for the best approach (adjusting blend func) but I assume that this will need a custom shader to render RGB windows.
apparently my investigation from comment #11 was wrong: I now have a custom shader and it's used but the windows are still black. Back to drawing board and this time I'm not going to share any analysis prior to me having figured out the problem to not further embarrass myself.
good news: I have window thumbnails for RGB windows. Now I just need to cleanup ;-)
Review Request: https://git.reviewboard.kde.org/r/118110/ It turned out that the GLXFBConfig was not matching the XPixmap's visual depth.
Git commit 9653fad2f026aacbd3c00d15eccd43e8de0fa4d3 by Martin Gräßlin. Committed on 13/05/2014 at 06:52. Pushed by graesslin into branch 'master'. [declarative/core] Use proper GLXFBConfig for glxpixmap We need to use a GLXFBConfig which matches the depth of the window pixmap's depth. So far it used the GLXFBConfig of the GL context. This worked fine for RGBA windows, but failed for RGB windows on e.g. some NVIDIA drivers. After this change the FBConfig of the context is completely ignored, instead it tries to find a good FBConfig for a given depth. Whenever a FBConfig for a given depth is found it's inserted in a cache shared between all WindowThumbnails so that we don't have the X roundtrips all the time. REVIEW: 118110 M +96 -32 src/declarativeimports/core/windowthumbnail.cpp M +1 -0 src/declarativeimports/core/windowthumbnail.h http://commits.kde.org/plasma-framework/9653fad2f026aacbd3c00d15eccd43e8de0fa4d3
Thanks Martin. Now it works (mostly of the time). I still get icons instead of thumbnails when moving the mouse over tasks. It is random. Sometimes it happens when the tooltip is moving from a task to another. Others when the tooltip is moving, it looks ok, but it shows a icon instead of a thumbnail when it stops over the task. Seems to be a running condition problem, like if two different methods can change the thumbnail. I can easily reproduce between a working state, icon only when tooltip is moving or icon when tooltip is stopped by hovering quickly the mouse over taskbar. I'll attach a screenshot that I was lucky to get with the icon instead of a thumbnail. All window are visible (not minimized) and the thumbnail was working fine before I started to hover the mouse over the taskbar. I noticed that the icon is pretty ugly (not SVG or very low res). Also, it is resided to match the window geometry. Sometimes, the shown icon is not from the task but from a previous window (even already closed) as ksnapshot showing konsole icon.
Created attachment 86759 [details] screenshot with icon instead of thumbnail
The screenshot shows Konsole, which is a special application. Could you please note down the applications for which you see a problem?
Created attachment 86774 [details] Another example, no konsole I reproduced it using system settings and chrome. Hovering over kickoff and desktop pager seems to help to reproduce the problem
Created attachment 87135 [details] screenshot with icon problem Thumbnails looks fine now. However, I still get random icon errors. Sometimes they got black, sometimes the same icon is used for following tasks.
Scaled up google chrome icon looks related to bug 335583
I think the icon problem is some sort of general Qt rendering issue; I get black task buttons, black text label rects and black icons intermittently. I don't think this is related to window thumbnails, which is the object of this bug report. Martin, can you comment on the attachment #19? I'd like to move forward with this ticket somehow.
(In reply to comment #22) > I think the icon problem is some sort of general Qt rendering issue; I get > black task buttons, black text label rects and black icons intermittently. I > don't think this is related to window thumbnails, which is the object of > this bug report. I assume you are on NVIDIA. Please try running with the threaded rendering loop. MartinK and I did some tests and it looks like those problem could be resolved using the threaded rendering loop. > > Martin, can you comment on the attachment #19? no sorry, that's unfortunately too little data to reproduce. And it's difficult for me to try to reproduce as my only NVIDIA system refused to start today -> we need more people being able to investigate such issues, it cannot be that X11-OpenGL interaction has a bus factor of 1.
> Please try running with the threaded rendering loop. Does that still require code changes? I vaguely remember we forced the non-threaded loop in code?
Created attachment 87314 [details] Screenshot of minimized Chrome task after restarting plasmashell The attached screenshot shows the tooltip of a minimized Chrome task after restarting plasmashell (to loose the tooltip). The icon scaling looks fine to me. Obviously the icon isn't sharp, but, well, that's because it _is_ scaled. I don't know whether the source is a pixmap prop on the window or it's moving through KIconLoader as Bhushan theorizes, though.
(In reply to comment #25) > I don't know whether the source is a pixmap prop on the window or > it's moving through KIconLoader as Bhushan theorizes, though. From experience with KWin: it's from the window property and chrome sets ridiculous small icons only.
Then I think we've got all the loose ends tied up for now and can close here.