| Summary: | redraw glitches over whole desktop with effects on | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Holger <h.klene> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | nate, plasma-bugs-null, postix |
| Priority: | NOR | ||
| Version First Reported In: | 5.19.5 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Screenshot of "transparent" thunderbird | ||
|
Description
Holger
2021-03-29 13:41:10 UTC
Sorry, the video 18.4 MB was too much for the issue tracker ... it is here: https://filehorst.de/d/dfqpbFau And all of these issues disappear if you turn off compositing with Alt+Shift+F12? (In reply to Nate Graham from comment #2) > And all of these issues disappear if you turn off compositing with > Alt+Shift+F12? Yes, I confirm. Alt+Shift+F12 immediately stops the glitches and I could not reproduce them while effects are off. Especially susceptible seem applications, that use a combination of mouse-scroll and mouse-hover events: e.g. the mail list in Thunderbird: 1. scroll the list a few times up and down using the mouse wheel (exposing about 10 lines of hight for the list) 2. move the mouse a few pixel up, so it hovers a different mail-subject 3. e.g. the last line in the message list quickly toggles at a high frequency between two mails before and after the last scroll. The flicker continues about half a second after the last mouse-move and restarts, even if the mouse moves out of the window - but only as long, as it moves. I was suspecting other effects like transparency and invert, that I also regularly use, but I could reproduce without such a window on screen. Do you still experience this issue with latest KWin 5.24.2 with X11 or Wayland? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! I'm still waiting to Kubuntu 22.04 to ship a more recent version of KWIN For now I'm stuck with: $ apt list kwin* Auflistung… Fertig kwin-addons/impish,now 4:5.22.5-0ubuntu1 amd64 [installiert] kwin-common/impish,now 4:5.22.5-0ubuntu1 amd64 [installiert] kwin-data/impish,impish,now 4:5.22.5-0ubuntu1 all [installiert] ... As for this bug, at least it got a whole lot better, so I don't see this anymore with KDE apps. Still, TV-Browser has some issues with the "darken parent effect" for it's subdialogs of subdialogs. For the first layer of dialog it does not darken the parent at all! After closing a dialog in the 3rd or 4th layer, it suddenly redraws the "fading" darkness over the main-parent about 10 times interleaving with 10 times drawing the non-darkened parents. After this automatic fire stops, it might trigger a few more times by moving the mouse and hovering different mouse-over effects of buttons/checkboxes. Also characteristic for this is, that this flaking darkness does not fully cover the parent window, but only a bunch of arbitrary rectangles. I can only assume, that the java-code is not quick enough to draw the GUI for every fading increment? Or Java uses some low-level access to put it's bits into the screen-buffer at it's own sweet time? At least the darkness is lifted completely once I return to the main window, unlike bug 450350, where the "darkness" lives on it's own :) TV-Browser Version: 4.2.4 Plattform: Linux 5.13.0-37-generic System: amd64 Java-Version: 17.0.1 OpenJDK 64-Bit Server VM Eclipse Adoptium /opt/jdk-17.0.1+12 Created attachment 147870 [details]
Screenshot of "transparent" thunderbird
Today, I managed a screenshot of Thunderbird. It features a "transparent" area showing the background. And the menubar is moved off it's top position to the middle of the window.
It happens on resizing the Thunderbird from windowed to maximized and back. The tranparancy is "true" - moving Thunderbird to a different location, will paint any underlying windows inside Thunderbird. On mouse over of Thunderbird elements, they get redrawn to their supposed location one by one.
Workarounds:
- Either minimize and restore the window
- or drag the border to resize the window
- switch Desktop
- disable/enable effects by Shift+Alt+F12
Any will immediately fix all drawing issues unless the window is maximized and restored again.
The Plasma effect of quickly stretching the window content without explicit redrawing the contents is NOT in use.
The Plasma effect of transparent see-through on moving the window is in use. But turning it off, has no impact on this bug.
If Plasma-effects are globally off, the former transparent area will be solid black.
Update to Kubuntu 22.04 - kwin 4:5.24.4-0ubuntu1 amd64 - Thunderbird 91.9.1 is still partially transparent between maximize / restore. |