https://bugs.kde.org/show_bug.cgi?id=443434
Vlad Zahorodnii <vlad.zahorod...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |RESOLVED
Resolution|--- |FIXED
Latest Commit| |https://invent.kde.org/plas
| |ma/kwin/commit/81f9da17fd9f
| |367883b1fca02c7eb3a3ebaa1c3
| |4
--- Comment #2 from Vlad Zahorodnii <vlad.zahorod...@kde.org> ---
Git commit 81f9da17fd9f367883b1fca02c7eb3a3ebaa1c34 by Vlad Zahorodnii.
Committed on 05/01/2022 at 17:00.
Pushed by vladz into branch 'master'.
Drop resize effect
After recent refactor changes to improve resizing of xdg-toplevel
surfaces with an aspect ratio, the resize effect got really broken. The
resize effect has always been a problem child on wayland.
Unlike X11, geometry updates are performed asynchronously on Wayland.
It's not possible to have a smooth transition after finishing
interactive resize from the resized state to the normal state, geometry
will jump from last moveResizeGeometry() to the current frameGeometry()
and when the client repaints the window, the window size will jump back
to the move resize geometry size. There are no ways to fix that without
contradicting to how the effect is advertised to work, e.g. sending
configure events behind the back. Keeping the frame geometry out of sync
with the xdg_surface window geometry size is also not the option,
geometry updates are already too complex (due to being async).
Another wayland related issue with the resize effect is that the
compositor doesn't know about aspect ratio or any other size
constraints, except min and max size. The client can provide a smaller
buffer to account for various geometry constraints. It will be confusing
to have a mismatch between resize outline and the final real geometry.
Aspect ratio or other geometry constraints won't be exposed to the
compositor, it's a common decision of many wayland devs (including KDE).
To some extent, the wayland issues can be addressed by performing content
updates, with active feedback, the mismatch between outline and the
final geometry would become less severe, but it won't be any different
than resizing without the effect.
Given the wayland issues and in part maintenance costs, this change
drops the resize effect. Note that it can be still reimplemented without
kwin core changes, but it would still suffer from the aforementioned
issues.
M +1 -12 src/abstract_client.cpp
M +0 -10 src/abstract_client.h
M +0 -1 src/effects/CMakeLists.txt
D +0 -28 src/effects/resize/CMakeLists.txt
D +0 -17 src/effects/resize/main.cpp
D +0 -56 src/effects/resize/metadata.json
D +0 -149 src/effects/resize/resize.cpp
D +0 -65 src/effects/resize/resize.h
D +0 -15 src/effects/resize/resize.kcfg
D +0 -57 src/effects/resize/resize_config.cpp
D +0 -43 src/effects/resize/resize_config.h
D +0 -45 src/effects/resize/resize_config.ui
D +0 -5 src/effects/resize/resizeconfig.kcfgc
M +1 -1 src/libkwineffects/kwineffects.h
M +1 -3 src/x11client.cpp
https://invent.kde.org/plasma/kwin/commit/81f9da17fd9f367883b1fca02c7eb3a3ebaa1c34
--
You are receiving this mail because:
You are watching all bug changes.
