Bug 443971 - Present windows effect in desktop grid is jumpy at the beginning or end
Summary: Present windows effect in desktop grid is jumpy at the beginning or end
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-desktop-grid (show other bugs)
Version: 5.23.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
: 451402 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-10-18 12:27 UTC by bastimeyer123
Modified: 2022-06-16 16:02 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25


Attachments
0042d2d8.patch (13.11 KB, patch)
2021-10-18 19:54 UTC, breakingspell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bastimeyer123 2021-10-18 12:27:17 UTC
SUMMARY
I've noticed this after the recent 5.23 upgrade on the Wayland session.

When both the desktop grid and the present windows effects are enabled, the desktop grid effect is using the present windows effects for showing the individual windows in its various tiles.

The present windows effect itself is showing an animation of the window positions, so that windows don't suddenly jump to their position in the presentation layout. This is working as intended.

However, in the desktop grid after the 5.23 upgrade on wayland, this window animation is missing for both the transition-in and transition-out phases of the desktop grid, which means the windows suddenly jump to their presentation positions. This is especially noticable for maximized windows when selecting a desktop from the grid where it zooms back in.

STEPS TO REPRODUCE
1. enable desktop grid and present windows effects
2. use a 3x3 grid layout and any present windows layout (eg. natural layout)
3. have multiple windows open, one of them maximized
4. toggle the grid
5. toggle grid again

OBSERVED RESULT
The individual windows suddenly jump to their positions in the tile's window presentation layout. When selecting the desktop again from the grid (aka. zooming back in), the window jumping is very noticable and distracting, especially for maximized windows.

EXPECTED RESULT
The desktop grid animation and present windows animations should both work at the same time, so that windows smoothly move to their intended positions, just like when toggling the present windows effect alone.

SOFTWARE/OS VERSIONS
Linux: Arch
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
This was not the case prior to 5.23 on the X11 session, and everything was working as expected.
Comment 1 bastimeyer123 2021-10-18 12:42:06 UTC
Also moving windows to a different dekstop when the grid is activated clearly shows the missing animations in the present windows effect. The window layout suddenly changes.
Comment 2 breakingspell 2021-10-18 19:54:27 UTC
Created attachment 142588 [details]
0042d2d8.patch
Comment 3 breakingspell 2021-10-18 19:55:03 UTC
I am also encountering this issue with the 5.23 release of kwin, using X11.

It seems to be related to this change, as rolling back the commit resolves the animation issue on my end: https://invent.kde.org/plasma/kwin/-/commit/0042d2d8c141e914c4a2bd7086e669b11771a78a. I've attached a patch to test with. 

Note that this patch also reverts https://invent.kde.org/plasma/kwin/-/commit/29d1b25ad584faf3b66d5b38f4075a00773c9c0f; reverting this commit alone did not resolve the issue for me, while the next commit did.
Comment 4 bin70086 2021-11-10 13:30:13 UTC
I'm also seeing this bug on both Wayland and X11. Had to roll back to 5.22 to make my desktop usable again . Surprised this hasn't been fixed after three bugfix releases.
Comment 5 Michael D 2021-12-18 10:03:06 UTC
Hopefully in the near future the overview effect is used instead of present windows.
Comment 6 breakingspell 2022-01-24 21:18:08 UTC
Revisiting this, the issue persists in 5.23.5 and 5.24 beta. I've been patching each update to revert commit 0042d2d8c141e914c4a2bd7086e669b11771a78a to no ill effects, as I use a shortcut to trigger the Desktop Grid rather than a gesture. I notice right away in a fresh install when this animation is missing while invoking Desktop Grid, and i'm surprised this regression hasn't been more widely reported as it seems to be the default configuration. 

The Overview effect is slated to replace the deprecated Present Windows effect, but it's still in progress under 5.24 beta. I believe this issue only lies in the desktop grid's tree regardless, Present Windows still functions properly on it's own in 5.24.
Comment 7 Michael D 2022-01-25 08:49:50 UTC
Thanks for the patch. Yes, does seem an issue with the grid, and yes, would be nice if this were fixed sooner than later since it's the main way I intertact with virtual desktops.
Comment 8 bin70086 2022-01-25 21:57:52 UTC
To add insult to injury, not only does 0042d2d8c141e914c4a2bd7086e669b11771a78a break the animation for everyone, but the  "realtime gesture" thing itself is absolutely terrible and breaks the touchpad experience as well. No idea why the commit was accepted in the first place. Also no idea why the bug caused by it, which breaks a major way of interacting with virtual desktops, has gotten absolutely no attention from developers. Is there even a point in submitting bug reports if they get ignored anyway?
Comment 9 goingtosleep 2022-02-08 14:44:51 UTC
Please fix this issue. Overview effect is not as smooth as Desktop Grid, feel very rough using Overview.
I have been waiting since 5.23.0, even bookmark this page and check every new release 😞
Comment 10 bastimeyer123 2022-02-09 15:30:08 UTC
I would really appreciate if this issue could be fixed. This bug makes working with the desktopgrid a really unpleasant experience, and the desktopgrid is an essential part of my desktop workflow.

Until 5.24.0 I was able to revert the commit which broke the present windows effect inside the desktopgrid effect, but this isn't possible anymore and it now requires solving merge conflicts and changing some more stuff. I've tried that and had some quick attempts at fixing the issue, but without success because I don't know anything about the internals of kwin and this is a bit overwhelming for me.

Here's the history of the desktopgrid effect:
https://invent.kde.org/plasma/kwin/-/commits/v5.24.0/src/effects/desktopgrid

As already mentioned, the commit which broke the present windows effect is this:
0042d2d8c141e914c4a2bd7086e669b11771a78a ("effects/desktopgrid: port to realtime gestures")
And the following two commits were necessary to revert too, as they apply minor changes on top of that:
b376f8832f20d69dc8dabe5ce75c87ddde7b7444 ("Fix desktop grid border activation")
29d1b25ad584faf3b66d5b38f4075a00773c9c0f ("effects/desktopgrid: Schedule repaint when toggled")

0042d2d8c141e914c4a2bd7086e669b11771a78a does a little bit more though than "porting to realtime gestures" from what it looks like, and it replaces the `setActive` method in favor of the `activate` and `deactivate` methods. It also changes the `prePaintScreen` method, and here, the `timeline` calculation is a bit different and it changes how the `finish` method gets called after the animation has finished. My guess is that the issue lies here.

This seems to be the relevant change, but I might be wrong (second link shows the current state on v5.24.0):
https://invent.kde.org/plasma/kwin/-/commit/0042d2d8c141e914c4a2bd7086e669b11771a78a#646809c6b03e31d2cd72be1a027121f3802fbbd4_173_224
https://invent.kde.org/plasma/kwin/-/blob/v5.24.0/src/effects/desktopgrid/desktopgrid.cpp#L222-228

`WindowMotionManager.calculate` receives the value of `timeline.currentTime()` instead of `time`, and one of the `timeline.setCurrentTime()` calls is now guarded by `timelineRunning` which gets set to true or false in the callback functions defined above.

The `finish` method now gets called in a callback added to the event loop, and it doesn't check for `!(isUsingPresentWindows() && isMotionManagerMovingWindows())` anymore:
https://invent.kde.org/plasma/kwin/-/commit/0042d2d8c141e914c4a2bd7086e669b11771a78a#646809c6b03e31d2cd72be1a027121f3802fbbd4_178_230
https://invent.kde.org/plasma/kwin/-/commit/0042d2d8c141e914c4a2bd7086e669b11771a78a#646809c6b03e31d2cd72be1a027121f3802fbbd4_157_206
Comment 11 Maximilian Böhm 2022-02-10 01:28:27 UTC
I just found this bug report, glad I’m not the only one! Have this broken transition since Plasma 5.23 and it’s still in 5.24.
I’ve made a video demonstration: https://youtu.be/lPGfMIgAhP8

And to the topic of the new Overview effect: It cannot replace the Grid! In the grid, you can see all your workspaces in a panoramic fullscreen view – where you can interact with the windows, e.g. for making them visible on all workspaces via a right-click. The Overview is a carbon-copy of macOS’ Mission Control and it does make workspace management indeed simpler – for simpler users, primary on notebooks. If you have a desktop PC and you are a power-user who wants to have total control over lots of windows and as less necessary clicks as possible, the Overview effect is not for you. Please don’t let the Grid rot so you can kick it easier in favor of the beginner- but not power-user-friendly Overview.
Comment 12 breakingspell 2022-02-10 09:20:54 UTC
(In reply to bastimeyer123 from comment #10)

Excellent notes, I hope they help the developers pin down a quick fix for this particular feature. Are we sure the right people were properly notified, just by submitting this bug report thread? I see duplicate reports of this same issue, the only one that has any discussion is this report, and the only one that was acknowledged (last release) was https://bugs.kde.org/show_bug.cgi?id=444678. There was even an unrelated regression caused by this commit that has already been fixed: https://bugs.kde.org/show_bug.cgi?id=442518. 

I tried to work the previous patch/diff into the current code earlier today, but as you noted too much has changed and the issue should simply be addressed. Going to roll back to 5.23 for now and cross fingers that this gets the eyes it needs.

(In reply to Maximilian Böhm from comment #11)

I must agree that the new Overview is a step apart from the Desktop Grid workflow many users have become accustomed to, and it would be a game-breaker if the grid were to be phased out for good. It's beyond useful hitting a hotkey for a snappy exploded view of all windows across desktops, then a single click to zoom directly to that window and focus it for input. I use window rules too, so I can know precisely where my applications are across 4 virtual desktops and 2 screens. The MacOS/Gnome-inspired vision does not work this way fundamentally, and while an upcoming "show all desktops" function for the Overview sounds interesting, isn't that what the Desktop Grid + Overview effect should accomplish? 


Slightly off-topic for this report, but Windows 10 has a small cosmetic issue cosmically similar to the Kwin bug we're looking at here, and it drives me up the wall just the same. 
When the ill-fated Timeline feature was integrated into the existing (and fully functioning) Task View in 2018, it introduced animation/pop-in stutter when entering and exiting the overview grid that persists to this day, even if Timeline is stubbed out. Anyone can observe it on a clean install of the latest Win10 on any hardware/vm, but discussion on the issue never went far outside of "oh wells", as there's no real way to bring a specific issue like that to Microsoft to fix (not to mention the lack of attention around the Task View feature in the first place). Makes me appreciate the community here that's willing to put their own time and effort in to pin down issues.
Comment 13 bastimeyer123 2022-02-10 18:36:15 UTC
Btw, this bug also affects moving windows between desktops on the desktop grid. The windows instantly jump into their positions instead of being moved/animated.

Why has this issue not been confirmed by the maintainers yet? The current status is still "reported".
Comment 14 Bug Janitor Service 2022-02-11 00:13:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1998
Comment 15 bastimeyer123 2022-02-11 00:44:09 UTC
The current diff from MR 1998 does not fix the issue:
https://invent.kde.org/plasma/kwin/-/commit/af185b23f77587d437dad381a01b4d75a7e7c422.patch

I've already mentioned that I tried fixing it, and this was one of my attempts. What this does fix is the zoom-out (open grid) and move-windows animation, but the zoom-in (close grid) animation is still broken which is probably caused by the new callback of the `finish()` method, as I described earlier.
Comment 16 Vlad Zahorodnii 2022-02-11 09:19:35 UTC
Git commit c0cb349cb8a27bc384f9e0b68ed95ebace9faa60 by Vlad Zahorodnii, on behalf of Jan Blackquill.
Committed on 11/02/2022 at 09:04.
Pushed by vladz into branch 'master'.

effects/DesktopGrid: use delta, not absolute time for MotionManager

Despite the argument naming, the input for WindowMotionManager::calculate is supposed to be a
delta, not an absolute time. Giving it a delta fixes the PresentWindows in the DesktopGrid.

M  +1    -1    src/effects/desktopgrid/desktopgrid.cpp

https://invent.kde.org/plasma/kwin/commit/c0cb349cb8a27bc384f9e0b68ed95ebace9faa60
Comment 17 Vlad Zahorodnii 2022-02-11 09:23:21 UTC
Git commit 78c483ab55b3b8e93580726cae6821f3a8f7703d by Vlad Zahorodnii, on behalf of Jan Blackquill.
Committed on 11/02/2022 at 09:23.
Pushed by vladz into branch 'Plasma/5.24'.

effects/DesktopGrid: use delta, not absolute time for MotionManager

Despite the argument naming, the input for WindowMotionManager::calculate is supposed to be a
delta, not an absolute time. Giving it a delta fixes the PresentWindows in the DesktopGrid.


(cherry picked from commit c0cb349cb8a27bc384f9e0b68ed95ebace9faa60)

M  +1    -1    src/effects/desktopgrid/desktopgrid.cpp

https://invent.kde.org/plasma/kwin/commit/78c483ab55b3b8e93580726cae6821f3a8f7703d
Comment 18 Viktor Kuzmin 2022-02-17 07:11:28 UTC
For me problem is only partially fixed. I'm already on 5.24.1 kwin. And my setup is XPS 7590 with 3840x2160 screen. Also I have 6 virtual desktops (3x2).

The problem is with presentwindows effect inside desktopgrid effect. It works OK on zoom out (presenting), but it doesn't work on zoom in. Windows are returned to wrong positions and last frame make sudden jump of windows to their normal positions.
Comment 19 bastimeyer123 2022-03-19 15:05:17 UTC
Looks like the commit which broke the desktop-grid effect (see my comment #10) was reverted and then added back twice on KWin's master branch for some reason...

First revert (without any comments/explanations):
https://invent.kde.org/plasma/kwin/-/commit/154528cdef5f175e038934fb57932cb1f5c25fe0
First restore:
https://invent.kde.org/plasma/kwin/-/commit/2de09fa249b1dd50ee92978927586f60118a91d0

Second revert:
https://invent.kde.org/plasma/kwin/-/commit/ca7fc44814251d348e830f6350df4caf2e70d624
Second restore (and report to KDE sysadmins for abuse):
https://invent.kde.org/plasma/kwin/-/commit/ec759434252c6a67e4739de8b4772d0ff885402f

The same user who implemented the realtime gestures and who committed the two reverts also submitted the partial bugfix in MR 1998:
https://invent.kde.org/plasma/kwin/-/merge_requests/1998

As confirmed by other users here in this thread, this issue is still present in the closing/zoom-in animation. Please see my comment #10 for where I think the issue lies. I unfortunately lack the experience with C++, Qt and KWin for fixing this and I would really appreciate it if one of the developers could take a look at this.
https://bugs.kde.org/show_bug.cgi?id=443971#c10
Comment 20 Nate Graham 2022-03-27 01:14:30 UTC
*** Bug 451402 has been marked as a duplicate of this bug. ***
Comment 21 Maximilian Böhm 2022-04-18 12:39:21 UTC
Any development on this? Tonight, I have even dreamed about this nasty bug…
Comment 22 Marco Martin 2022-05-06 10:44:44 UTC
Git commit 7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42 by Marco Martin.
Committed on 06/05/2022 at 10:44.
Pushed by mart into branch 'master'.

QML version of the Desktop Grid effect

Replace completely the old desktop grid effect with a QML version.
Aims to feature parity and be a change as transparent as possible for the user.
Related: bug 433071, bug 452625, bug 437121, bug 452925, bug 437928, bug 452439, bug 288530, bug 450254, bug 450106, bug 447832, bug 449960, bug 416576, bug 441862, bug 444859, bug 445999, bug 422117, bug 404627, bug 435483, bug 420744, bug 435482, bug 427055, bug 333445, bug 429120, bug 427391, bug 409295, bug 294322, bug 356955
FIXED-IN: 5.25

M  +5    -0    src/effects.cpp
M  +10   -5    src/effects/desktopgrid/CMakeLists.txt
D  +0    -1571 src/effects/desktopgrid/desktopgrid.cpp
D  +0    -186  src/effects/desktopgrid/desktopgrid.h
D  +0    -32   src/effects/desktopgrid/desktopgrid.kcfg
M  +6    -14   src/effects/desktopgrid/desktopgrid_config.cpp
M  +2    -2    src/effects/desktopgrid/desktopgrid_config.h
M  +68   -144  src/effects/desktopgrid/desktopgrid_config.ui
A  +32   -0    src/effects/desktopgrid/desktopgridconfig.kcfg
M  +5    -1    src/effects/desktopgrid/desktopgridconfig.kcfgc
A  +342  -0    src/effects/desktopgrid/desktopgrideffect.cpp     [License: GPL(v2.0+)]
A  +108  -0    src/effects/desktopgrid/desktopgrideffect.h     [License: GPL(v2.0+)]
M  +5    -4    src/effects/desktopgrid/main.cpp
D  +0    -26   src/effects/desktopgrid/main.qml
M  +1    -0    src/effects/desktopgrid/metadata.json
A  +255  -0    src/effects/desktopgrid/qml/DesktopView.qml     [License: GPL(v2.0+)]
A  +193  -0    src/effects/desktopgrid/qml/main.qml     [License: GPL(v2.0+)]
M  +22   -5    src/effects/private/qml/WindowHeap.qml
M  +21   -3    src/libkwineffects/kwineffects.h
M  +4    -1    src/libkwineffects/kwinquickeffect.cpp

https://invent.kde.org/plasma/kwin/commit/7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42
Comment 23 Maximilian Böhm 2022-05-06 22:17:37 UTC
(In reply to Marco Martin from comment #22)
> Git commit 7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42 by Marco Martin.
> Committed on 06/05/2022 at 10:44.
> Pushed by mart into branch 'master'.
> 
> QML version of the Desktop Grid effect
> 
> Replace completely the old desktop grid effect with a QML version.
> Aims to feature parity and be a change as transparent as possible for the user.

Does this rewrite have right-click to make a window available on all workspaces? A transition effect? Big screen space utilizing window previews like in the classical "present windows", different from the tiny window previews in the new Overview effect?