Bug 348577 - DesktopButtonsView windows are not sufficiently unreferenced
Summary: DesktopButtonsView windows are not sufficiently unreferenced
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/124...
Keywords:
: 351291 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-06-02 10:39 UTC by Stefan Majewsky
Modified: 2015-08-14 23:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.4
thomas.luebking: ReviewRequest+


Attachments
screenshot of problem (1.10 MB, image/png)
2015-06-02 10:40 UTC, Stefan Majewsky
Details
qdbus org.kde.KWin /KWin supportInformation (5.39 KB, text/plain)
2015-06-02 10:40 UTC, Stefan Majewsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Majewsky 2015-06-02 10:39:35 UTC
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.)
Comment 1 Stefan Majewsky 2015-06-02 10:40:21 UTC
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.
Comment 2 Stefan Majewsky 2015-06-02 10:40:43 UTC
Created attachment 92964 [details]
qdbus org.kde.KWin /KWin supportInformation
Comment 3 Thomas Lübking 2015-06-02 13:13:10 UTC
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.
Comment 4 Stefan Majewsky 2015-06-02 16:34:35 UTC
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.
Comment 5 Thomas Lübking 2015-06-02 18:59:19 UTC
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.
Comment 6 Stefan Majewsky 2015-06-08 16:39:05 UTC
I tried disabling both effects at the same time and separately, but to no effect on the problem.
Comment 7 Thomas Lübking 2015-06-09 14:12:08 UTC
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?
Comment 8 Thomas Lübking 2015-06-19 11:44:18 UTC
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 ;-)
Comment 9 Thomas Lübking 2015-06-19 21:41:45 UTC
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.
Comment 10 Thomas Lübking 2015-08-14 13:32:33 UTC
*** Bug 351291 has been marked as a duplicate of this bug. ***
Comment 11 Thomas Lübking 2015-08-14 23:58:49 UTC
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