Bug 455450

Summary: Slide desktop animation is slower in 5.25, especially compared to other animations
Product: [Plasma] kwin Reporter: Prajna Sariputra <putr4.s>
Component: effects-variousAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: bastimeyer123, guimarcalsilva, july.tikh, kurnevsky, lee295012, nate, ppelikan, rybak.a.v
Priority: NOR Keywords: regression, usability
Version: 5.25.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 5.26
Attachments: Comparison between slide desktop and some other animations

Description Prajna Sariputra 2022-06-17 01:05:51 UTC
Created attachment 149836 [details]
Comparison between slide desktop and some other animations

SUMMARY
Since upgrading to 5.25.0 I noticed that the animation speed when switching desktops with the slide effect (by scrolling on the desktop, the pager on the panel or via keyboard shortcuts) is significantly slower than before, but I don't see any other animations being changed that drastically. Increasing the global animation speed in System Settings does speed it up, however to make it feel like how it was in 5.24 all other animations end up near instant as a result.

I have attached a screen recording to show what the slide desktop animation looks like compared to some other animations (overview, showing the application launcher, window switching via Alt+Tab, show desktop).

STEPS TO REPRODUCE
1. Enable the slide desktop animation
2. Switch to another virtual desktop using a keyboard shortcut or scrolling on the desktop or scrolling on the pager
3. Observe the animation speed

OBSERVED RESULT
The animation is much slower than others in Plasma (say opening the application launcher).

EXPECTED RESULT
The animation speeds should be at least somewhat consistent with the rest of the system.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.25.0
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4
Kernel Version: 5.18.3-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 530

ADDITIONAL INFORMATION
My touchpad unfortunately only supports two fingers, and I also don't have a touchscreen, so the one to one animation thing doesn't help in my case. My mouse wheel doesn't have high precision or anything like that either, it's just a Logitech M90, which is like the cheapest mouse I found in the store I bought it from.
Comment 1 Vlad Zahorodnii 2022-06-17 07:02:33 UTC
We changed the mechanics of the slide animation in 5.25. In 5.24 and before, we used to use an easing curve. In 5.25, the slide effect uses a spring physics model for animation. We made that change in order to make the animation when pulling fingers from touchpad look good.

We can expose spring parameters, but arguably, such level configurability would be too advanced and people will struggle with it.
Comment 2 Prajna Sariputra 2022-06-17 08:08:53 UTC
(In reply to Vlad Zahorodnii from comment #1)
> We can expose spring parameters, but arguably, such level configurability
> would be too advanced and people will struggle with it.

Looking through the KWin effects I have installed I noticed that the Wobbly Windows effect exposes its advanced parameters (stiffness, drag and move factor), so would the spring parameters be any more complicated than those?
Comment 3 Nate Graham 2022-06-17 18:22:57 UTC
I'm really not a fan of allowing this level of configurability. We should aspire to make it feel good by default (which it already does IMO) and make sure it follows the global animation speed slider (which it already does). Anything beyond that seems like extreme over-configurability to me.
Comment 4 Prajna Sariputra 2022-06-18 00:21:33 UTC
Fair enough, so I guess this counts as intentional as part of adding support for the one to one animation (feel free to mark it so if that's the case).

Fortunately after about a day it doesn't feel anywhere near as annoying as it did right after the upgrade, and I haven't seen anyone else mention it so it's probably just me then lol.
Comment 5 Nate Graham 2022-06-21 16:01:28 UTC
Hehe
Comment 6 Vlad Zahorodnii 2022-06-28 11:31:21 UTC
*** Bug 456070 has been marked as a duplicate of this bug. ***
Comment 7 Andrei Rybak 2022-06-28 11:51:44 UTC
> I'm really not a fan of allowing this level of configurability. We should aspire to make it feel good by default (which it already does IMO) and make sure it follows the global animation speed slider (which it already does). Anything beyond that seems like extreme over-configurability to me.

Oh no.

I have global animations two notches faster than the default, and the virtual desktop slide animation is still way too slow in 5.25.1 (https://bugs.kde.org/show_bug.cgi?id=456070). And now I have to force all other animations to be unnecessarily fast if I don't want to wait through the slow as molasses virtual desktop slide animation.

Sounds like this part of KDE isn't "powerful when needed" anymore. https://kde.org/announcements/plasma/5/5.10.0/ This is very sad to hear.
Comment 8 guimarcalsilva 2022-07-01 18:51:30 UTC
*** Bug 456218 has been marked as a duplicate of this bug. ***
Comment 9 guimarcalsilva 2022-07-01 18:53:43 UTC
Sorry. I had just filled a bug report about this after the discussion in bug 450268, but I realized it was a duplicate of this one.

I believe this should be reopened and the default values for the spring physics model should be adjusted to match the global animation speed setting. More details can be seen on the bug I closed as a duplicate.
Comment 10 guimarcalsilva 2022-07-01 19:20:18 UTC
>At the default global animation speed, on a 60hz screen, it took on average 50 frames for the slide animation to complete, while the overview took on average 15 frames and opening Kickoff took around 8 frames. The new effect has an animation factor which is too big compared to most of the other effects. It should probably take the same amount of time to complete as the overview effect, which is also a fullscreen effect. Making the speed consistent with other full screen effects should improve user complaints and let devs avoid adding redundant per-effect speed settings to work around the issue.

This is part of the description of the duplicate bug. In this case, I believe the values for the spring physics model could be tweaked to make the animation speed consistent with the overview effect (which is also a fullscreen effect). I believe the problem here is that the values chosen make the animation visibly slower compared to everything else when not using touch, and the user has to speed up the global animation scale to make the slide effect have a reasonable speed, which in turn makes the other animations almost instantaneous.

I do agree though that it's not ideal to expose those values to users. Making users fix the problem manually is never ideal.

If trying to match the animation speed to the overview effect makes the simulation feel bad when using a touch screen, would it be possible to detect when the movement is started from a drag or from a click and use different settings?
Comment 11 Prajna Sariputra 2022-07-02 01:57:15 UTC
I suspect another possible issue with trying to make the animation speed consistent with the other effects is that it might not be possible (or at least straightforward) to make it do so at all possible global animation speed settings, I remember dropping the global animation speed to the minimum and timing how long the effects took when I was about to file this bug report, and some of the other effects I tested seem about as slow (if not slower) than the slide effect, unlike on the normal animation speed I use.
Comment 12 Nate Graham 2022-08-15 17:55:46 UTC
*** Bug 457875 has been marked as a duplicate of this bug. ***
Comment 13 Evgeny 2022-08-15 21:18:27 UTC
I created one more duplicate of this issue, sorry for that. I ended up patching kwin to make slide faster, here how it can be done in nix in case somebody is interested: https://github.com/kurnevsky/nixfiles/commit/c77a7662428cfa988a624f9db0e442669242fb93
Comment 14 Nate Graham 2022-08-17 15:45:48 UTC
Feel free to submit that upstream. The last "change the speed" patch that was submitted got merged.
Comment 15 Nate Graham 2022-09-21 20:32:58 UTC
*** Bug 459357 has been marked as a duplicate of this bug. ***
Comment 16 Nate Graham 2022-09-21 20:33:49 UTC
We keep getting bug reports about this; it's clear that users aren't happy about the slower effective speed of the Slide effect in 5.25 and later. Re-opening.
Comment 17 Bug Janitor Service 2022-09-28 10:16:50 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3009
Comment 18 Evgeny 2022-09-28 10:27:09 UTC
(In reply to Bug Janitor Service from comment #17)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/kwin/-/merge_requests/3009

Well, for myself I increased it to 500 :)
I have a feeling that increasing to 250 won't make a big difference, probably those who created issues can comment as well.
Comment 19 Vlad Zahorodnii 2022-09-28 11:10:06 UTC
500 is too high for me personally
Comment 20 Evgeny 2022-09-28 11:18:35 UTC
The problem here is not just that the slide animation is slow. The main problem is that its time is not aligned with other animations, so it's impossible to configure it with global animations speed setting. I believe it should be somewhere around 400 to be close to the speed of other animations.
Comment 21 Vlad Zahorodnii 2022-09-28 12:10:44 UTC
The spring animation has no well defined duration, its duration is dependent on how much the slide effect needs to slide. Sometimes it can be quicker, sometimes it can be longer. I think the best way to move forward is to gradually tweak the spring parameters until enough people are pleased with it.
Comment 22 Prajna Sariputra 2022-09-28 12:13:50 UTC
I just tested changing that parameter to 250, 300 and 500, here's what I feel regarding these options:

500: Way too fast compared to the other animations, and yet simultaneously it also feels like how it was in 5.24 and before. I think this is because the new animation mechanism makes the ending in particular relatively glacial, while other animations either have a constant speed or even speed up towards the end, and it is the ending that I would notice the most because that is when I end up waiting for the animation to finish before moving on. So, with the new animation mechanism the top speed ends up having to be higher in order for the overall speed to match the old one, which was more constant speed wise.

250: Not a big change, doesn't quite nail it for me still but it is certainly an improvement over the current setting of 200.

300: This feels good to me, noticeably faster over the current setting of 200 and yet not super fast like 500. One metric that this option meets for me that the slower options don't is how long it feels like things are still moving around/not yet settled once my finger stops touching the keyboard (this I think is what led me to post this bug report in the first place, although I did not realise exactly what it was back then). To put it another way, starting from the global animation speed setting which I find comfortable for the other animations I have to bring it up two notches to make the slide effect work nicely with 200, while with 250 I only need to raise the global speed one notch, and finally with 300 is where I don't feel any urge to tweak it any more.

In short, I think if that parameter was set to 300 when 5.25 came out I probably wouldn't have noticed much of a difference, certainly wouldn't have bothered to create a bug report about it.

Still, I can certainly make do with 250, while it still means I have to raise the global animation speed one notch above the ideal point that's better than two (which makes other animations blindingly fast), and I highly appreciate that the change has been made in response to our feedback, so thanks so much!
Comment 23 Vlad Zahorodnii 2022-09-28 15:41:10 UTC
Git commit 4c07daec3f7d16c58cf039164e706dd0363b2557 by Vlad Zahorodnii.
Committed on 28/09/2022 at 15:41.
Pushed by vladz into branch 'master'.

effects/slide: Increase spring constant

We've got complaints that the animation is too slow.

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

https://invent.kde.org/plasma/kwin/commit/4c07daec3f7d16c58cf039164e706dd0363b2557
Comment 24 Vlad Zahorodnii 2022-09-28 15:41:42 UTC
Git commit 5b97cd02ec10a87dedb9038abcad438129995e54 by Vlad Zahorodnii.
Committed on 28/09/2022 at 15:41.
Pushed by vladz into branch 'Plasma/5.26'.

effects/slide: Increase spring constant

We've got complaints that the animation is too slow.


(cherry picked from commit 4c07daec3f7d16c58cf039164e706dd0363b2557)

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

https://invent.kde.org/plasma/kwin/commit/5b97cd02ec10a87dedb9038abcad438129995e54
Comment 25 July Tikhonov 2022-10-18 11:14:12 UTC
The problem is not only in the speed itself, but in the uneven pacing of the animation. This is a direct consequence of the mass-spring-damper model: the motion starts off parabolically (with near-constant acceleration), but slows down exponentially (with acceleration and speed proportional to remaining distance). Therefore, the animation will always be either too fast at the beginning, or too slow at the end.

For all my love of physics, I would suggest dump the spring-damper model. Sometimes the most elegant solution is not good enough. (Personally, I have patched the SpringMotion class to output a Bezier curve instead.)
Comment 26 bastimeyer123 2022-11-05 10:34:02 UTC
Btw, even though the springConstant value has recently been changed, there's still a massive difference in animation time when switching activities, which also uses the slide animation (or a different implementation, IDK). This seems to depend on whether your other activity is on the same virtual desktop, so you have to enable the setting for having independent virtual desktops for each activity first. I've patched the springConstant to 500.0 and dampingRatio to 1.05 respectively in order to make the different animation speeds somewhat align, with the downside of being a bit too fast.