Starting with 5.22.90 (5.22 was fine), when both the resize ("fast window scaling") and wobbly window effects are active, the window is shown "stuck" at its old size while the resize is in progress. Using either of those effects without the other works fine.
Can reproduce. Leaving severity at NOR for now since this only affects setups with two non-default effects simultaneously enabled by the user (or the distro, I guess, but then that's on them. :) )
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
Created attachment 146905 [details] The effect of missing fast windows scaling The fast windows scaling was a godsend for performance and helped to keep cpu and battery usage lower by avoiding useless repaints, it was extremely useful to smooth resize lagging windows like firefox or even the systemsettings one; Try to resize the systemsettings window; it is not a good show at all! The attachment shows what happens when a window don't redraw his content fast enough while you resize. My opinion is that has been killed in favour of an useless *option* of a "wow effect!" and that it can even leads to a uglier experience! So, instead of ditching the whole resize effect , may i suggest one of the following instead: 1) Disable the wobbly effect option for resize when fast window scaling is active 2) Disable the wobbly effect option for resize
(In reply to Vlad Zahorodnii from comment #2) > 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. Does it mean it can be implemented via js as an external effect?
(In reply to Antonio Orefice from comment #3) > Created attachment 146905 [details] > The effect of missing fast windows scaling > > The fast windows scaling was a godsend for performance and helped to keep > cpu and battery usage lower by avoiding useless repaints, it was extremely > useful to smooth resize lagging windows like firefox or even the > systemsettings one; > Try to resize the systemsettings window; it is not a good show at all! > The attachment shows what happens when a window don't redraw his content > fast enough while you resize. > > My opinion is that has been killed in favour of an useless *option* of a > "wow effect!" and that it can even leads to a uglier experience! > > So, instead of ditching the whole resize effect , may i suggest one of the > following instead: > 1) Disable the wobbly effect option for resize when fast window scaling is > active > 2) Disable the wobbly effect option for resize I also agree on the usefulness of the effect, made a bugzilla some hours prior about bringing it back
Would really love to see this effect make it back into KDE in some way. Removing this entirely seems like a bad way to go when it was working so well for some of us