| Summary: | DesktopButtonsView windows are not sufficiently unreferenced | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Stefan Majewsky <majewsky> |
| Component: | effects-window-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | n.schnelle |
| Priority: | NOR | Flags: | thomas.luebking:
ReviewRequest+
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/124136/ | ||
| Latest Commit: | http://commits.kde.org/kwin/c240f7a012fee783cb932cc334b999c2defaa238 | Version Fixed In: | 5.4 |
| Sentry Crash Report: | |||
| Attachments: |
screenshot of problem
qdbus org.kde.KWin /KWin supportInformation |
||
|
Description
Stefan Majewsky
2015-06-02 10:39:35 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.
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 |