See steps to reproduce. Reproducible: Always Steps to Reproduce: 1. Set KWin rendering backend to OpenGL (2.0 or 3.1), not XRender. 2. Trigger Desktop Grid with Ctrl-F8. 3. It doesn't happen when the Desktop Grid is toggled the first time after restarting kwin, so close it and trigger it once more. Actual Results: A section of the screen contents at the bottom right corner of the screen, prior to invocation of the desktop grid, is shown at the bottom right corner of every virtual desktop. (Will attach a screenshot.)
Created attachment 92963 [details] screenshot of problem Desktop grid was triggered from desktop 1 here. As you can see, the page number of my PDF is visible on every virtual desktop.
Created attachment 92964 [details] qdbus org.kde.KWin /KWin supportInformation
Not sure whether this is actually a bug (in kwin) - looks more like the "48" is in an override direct window. Could you run "xwininfo" from konsole and (while the desktopgrid is NOT active) click the section that shows on all desktops after the cursor turned "+"? The please post the output.
Nope, no override direct window. I just checked with xwininfo as you instructed, both before and after using the desktop grid (again with the faulty rendering), and it printed information about the Firefox window that is currently open and maximized.
Sounds reasonable if this is not reproducible w/ xrender. Wild guess: "kcmshell5 kwineffects", disable blur and contrast effects. Any change? If yes, try to configure the blur effect to not cache intermediate results.
I tried disabling both effects at the same time and separately, but to no effect on the problem.
Another wild guess would be FF hardware acceleration: open "about:config" / filter for "accel" set "layers.acceleration.disabled" to false (and ensure "layers.acceleration.force-enabled" is not set true) Is the url shown in the screenshot (or any other exposing this) publically accessible?
Just saw that - related to the add/remove buttons (the artifact area matches the scaled down area of the unscaled button area - easy to see on one owns desktop ;-)
It's actually a window with undefined content and it's "somehow" added by the QQuickView which forms the add/remove buttons. While the latter is skipped on painting the scaled desktop, this little surprise is not. Dev note: This likey also explains the artifacts of the taskbar thumbnail popups.
*** Bug 351291 has been marked as a duplicate of this bug. ***
Git commit c240f7a012fee783cb932cc334b999c2defaa238 by Thomas Lübking. Committed on 14/08/2015 at 23:35. Pushed by luebking into branch 'Plasma/5.4'. do the hide-is-move dance w/ desktopgrid buttons the (old) button effect windows used to be unreferenced with the re-invocation of the effect. because we stopped deleting/recreating the window, this approach failed and the effect window was never deleted. Unreferencing the window at proper occasion (see new hide location) coked up - guess what - the exact same "texture is junk" issue as for the QtQuick close button in present windows... So we resort to the exact same stupid "hide by moving" solution as we have there. FIXED-IN: 5.4 REVIEW: 124136 M +39 -18 effects/desktopgrid/desktopgrid.cpp M +7 -0 effects/desktopgrid/desktopgrid.h http://commits.kde.org/kwin/c240f7a012fee783cb932cc334b999c2defaa238