https://bugs.kde.org/show_bug.cgi?id=519789
Vlad Zahorodnii <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED Latest Commit| |https://invent.kde.org/plas | |ma/kwin/-/commit/3d770c8650 | |a70eb2128ee38e89d8360c15b82 | |191 --- Comment #10 from Vlad Zahorodnii <[email protected]> --- Git commit 3d770c8650a70eb2128ee38e89d8360c15b82191 by Vlad Zahorodnii. Committed on 10/06/2026 at 17:52. Pushed by vladz into branch 'master'. Mark X11 windows ready for painting when we start managing or tracking them Technically, the compositor may see the actual window contents slightly later. To handle such a case, kwin sends a sync request. However, it may happen that a window never becomes ready for painting. It can lead to problems if an effect wants to animate such a window. Effects usually reference windows to prevent from getting deleted, and animations are advanced when the window is visible. In other words, kwin will get stuck with a zombie window. There are definitely many options that we could use to address this issue, but most of them will either be too cumbersome or lead to other regressions. On a second look, if we make a window ready for painting right off the bat, it doesn't look that bad. There are no glitchy pixels or anything like that. So this change pivots for that approach. Co-authored-by: Xaver Hugl <[email protected]> M +0 -4 autotests/integration/dont_crash_aurorae_destroy_deco.cpp M +0 -3 autotests/integration/effects/translucency_test.cpp M +0 -8 autotests/integration/window_rules_test.cpp M +0 -1 autotests/integration/xwayland_dnd_test.cpp M +0 -5 autotests/integration/xwayland_input_test.cpp M +0 -1 autotests/integration/xwayland_selection_test.cpp M +3 -19 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/3d770c8650a70eb2128ee38e89d8360c15b82191 -- You are receiving this mail because: You are watching all bug changes.
