I have my global animation slider on the 8th mark too and it in no way feels "irritatingly fast" to me. Speed is always relative, but if we made this any slower by default we would surely get bug reports about the opposite thing: that it's become too slow, and people don't want to have to change their global animation speed to be faster to speed it up. I think we have to keep this the way it is, sorry.

*** Bug 455519 has been marked as a duplicate of this bug. ***

Nate, it is one step faster on 5.25 than on 5.24. I know have to lower the global speed setting one step lower than on 5.24 to get the speed elegance.
It might have been my mistake to combine this report with a recommendation for a general lowering, which you are refering to. But it is unmistakably faster than before. And it is faster than on macOS and the old Compiz too, which are my mental benchmarks.

Go grab a live CD with an older Plasma release and compare the two. This new implementation is clearly faster. Please reconsider this choice. ;(

Once again without typos:

Nate, it is one step faster on 5.25 than on 5.24. I now have to lower the global speed setting one step lower than on 5.24 to get the same speed elegance. I had it on the 8th mark and now I need to set it to the 7th to achieve the same – but this makes all other animations slower as well.

It might have been my mistake to combine this report with a recommendation for a general lowering, which you are refering to. But it is distinctive faster than before. And it is faster than on macOS and the old Compiz too, which are my mental benchmarks.

Go grab a live CD with an older Plasma release and compare the two. This new implementation is clearly faster. Please reconsider this choice. ;(

After doing a side-by-side comparison, I can indeed confirm that the implementation in Plasma 5.25 is animated more swiftly, that's especially apparent for the "window grid" effect and less apparent for "present windows".

While I am on the slower side of animations anyways – usually I have the speed settings on the 7th mark and only changed them for reproducing this bug – I do understand the appeal of a "snappy" UX by default. If that default changed over time to accustom the changing general animation expectations that'd be fine, it's just the the proportional speed of effects within the same speed setting needs to be wholistic and matching. And this speed change in the two effects mentioned is messing with this well-rounded proportions a bit.

Please re-consider this bug. I raised a thread on reddit: https://www.reddit.com/r/kde/comments/vnf5fx/desktop_grid_effect_on_plasma_525_is_too_fast/.
Looks like 100% of people commented agreed that the effect is too fast.

From my end, I think if nobody complains about the speed of the _old_ Desktop Grid, there won't be any if the _new_ one has a similar speed 😊

@cyberlyncx made a nice demonstration video that I think I should include here: https://youtu.be/d1isioNwgP4

I have made a video comparison in 60 fps 4K between the Plasma 5.25 reimplementations and their 5.24 speeds. First, I show you the 5.24 animations speed, then the 5.25 animations speed, followed by a side-by-side view, followed by this side-by-side-view in 50% video slowdown – for both Present Windows and Desktop Grid. You will probably see: It’s not just imagination, the speedups are real and they make the effects look worse.

https://youtu.be/d1isioNwgP4

To cite a Reddit user: »There are two kinds of animation: those who make the UI look fancy and those who are an important part of a feature. If you close a window and it e.g. fades out it mainly looks fancy. That can be fast, it can be slow, it doesn't change functionality. Desktop Grid on the other hand should communicate to the user were windows are moving in the overview, if that's to fast, the functionality breaks.«
https://www.reddit.com/r/kde/comments/vnf5fx/desktop_grid_effect_on_plasma_525_is_too_fast/

That’s what I was calling »downright irritatingly fast« and your dismissal of it just was »speed is always relative«.
This Reddit thead about the too fast Desktop Grid currently has 64 upvotes.

It’s not as obvious in the Present Windows effect but with a slower global speed setting, it feels more like in 5.24 too. My video comparison proves the claim about the visually faster speeds. Be sure to watch it in 60 fps.
I beg you to reconsider this choice. The new defaults trouble a lot of us users. ;(

As an every-10-minutes user of the Desktop Grid for quite a while, the effect is effectively broken for me in 5.25 due to the inconsistent animation speed relative to all other existing Kwin effects. The Zoom duration (formerly an exposed property in settings pre-refactor) does NOT match the global slider, and neither do the Windowheap arrangements. This is not a placebo, users here have already demonstrated with high-framerate recordings that mirror my own experience (X11 on 144hz monitors). 

The goal of the QML rewrite at https://invent.kde.org/plasma/kwin/-/commit/7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42 is to "be a change as transparent as possible for the user", and this animation mismatch goes against that description. For the Desktop Grid in particular, <5.22 had a fully featured grid effect and system-matching transitions, before animation bugs were introduced in 5.23. Shouldn't that experience be the example that the Deskop Grid's QML refactor intends to replace? It takes a little time to smooth things out in refactors, this and other issues shouldn't be dismissed out of hand! 

With this attached band-aid of a patch built on 5.25.2, the Desktop Grid+window transitions almost convince me that I am back on the 5.22-era grid (outside of other reported bugs with window layout). I have been pleased with this adjustment for a full work week, and I encourage anyone willing to try the patch and adjust the values for themselves to see if we can dig up what's going on. I've been comparing against the "Slide Back" Kwin window effect that does honor the global speed slider. 

I hope this helps to uncover an underlying issue that fixes all of the new effect durations at once. A quick fix for the Overview effect may work the same way, but I only use the Desktop Grid in day-to-day so that is the only component I focused on, and this patch is only to demonstrate that the animation duration can be adjusted to match the global animation experience, that the issue is not just in our heads. This problem needs to be considered across the board for these effects, as users like myself very much notice the difference between these animation behaviors in the last few versions.

The patch does the following:

    -  Doubles effect.animationDuration for the Desktop Grid and it's window heap section. You'd think that would be too much, but with this patch, Desktop Grid (and KDE as a whole) match my 5.22 preference animation preference EXACTLY. The windows even have the slight inertia bounce that they had before, the new "stiffness" of the animation is gone.
Is something causing the variable to be set to the wrong speed for these new effects, and is it actually an exact half of what it should be? I've tested this at different levels of global animation speed but not thoroughly (I use 9 marks on the global slider for work). I tried ranging the value between 1.2, to 1.8, 2.2 to 3x duration, only 2x feels correct. The adjustment must be consistent across all instances of the animationDuration variable, or the windows will reposition faster than the grid zoom duration, etc. I also considered that the global animation speed value can sometimes "stick" by becoming set under animationDurationFactor in kwinrc, this was not the case in my tests, the global slider was effective each time I adjusted. 

    - The exit animation/duration are still broken as well, unless effect.deactivate() is called by event.key. Currently this is only called by Esc key, the action of switching desktops, and Left Click/Tap. 
Shouldn't the activation hotkey also be defined as an exit action along with Esc to properly call the animation and other exit functions? This was the behavior in 5.22, one could enter and exit the grid without lifting a hand off the hotkey. Right now the activation hotkey will cause the exit animation to fly by at the wrong speed by while Esc and Left Click are smooth as silk and consistent with the global setting. 
I hardcoded the Tab key alongside Esc to test and it is present in the patch: this has worked for me to smoothly exit the grid with half of my hotkey (Win+Tab), but that is not a fix. My next challenge is going to be trying to work the grid activation hotkey in so it can be properly toggled with a double keystroke, it would be worth a Merge discussion at that point.

Created attachment 150424 [details]
Test changes to the animation effects in QML desktop grid

Re-opening since we have a merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/2781) that would resolve this, and in the end I have to acknowledge that it's probably the right thing to do. Looks like I was wrong here.

Git commit 1a475a73de3c7015db8e8a2a76113a770eb3e758 by Nate Graham, on behalf of Blake Sperling.
Committed on 09/08/2022 at 23:54.
Pushed by ngraham into branch 'master'.

effects: Improve animation durations and easing curves in Windowheap-based effects

This commit doubles the animation durations for WindowHeap-based effects
(Overview, Present Windows, and Desktop Grid) and uses the OutCubic easing
curve for their opening and closing animations. This makes them feel smoother
and more comfortable.
Related: bug 448538
FIXED-IN: 5.26

M  +1    -1    src/effects/desktopgrid/desktopgrideffect.cpp
M  +1    -1    src/effects/desktopgrid/desktopgrideffect.h
M  +2    -2    src/effects/desktopgrid/qml/DesktopView.qml
M  +5    -5    src/effects/desktopgrid/qml/main.qml
M  +1    -1    src/effects/overview/overvieweffect.cpp
M  +1    -1    src/effects/overview/overvieweffect.h
M  +1    -1    src/effects/private/qml/WindowHeapDelegate.qml
M  +7    -9    src/effects/windowview/qml/main.qml
M  +1    -1    src/effects/windowview/windowvieweffect.cpp
M  +1    -1    src/effects/windowview/windowvieweffect.h

https://invent.kde.org/plasma/kwin/commit/1a475a73de3c7015db8e8a2a76113a770eb3e758

Hi,

This is just a matter of taste/opinion, i guess... but as a heavy present windows/overview user, this is now way too slow. As using present windows as almost an alt+tab replacement, its now ... weird ...

Worse, i guess, is that it feels completely disconnected with other animation speeds: window opening, closing, fading, minimizing, plasma popups sliding.

for example: 
* sliding popups is 150ms
* slide (open/close) is 200ms and glide is 160ms
* fade is 150 ms


The issue with 400 for me, is that is completely set apart from the rest of kde's animations, making me unable to control it (set it faster, makes everything super fast... make everything "normal speed", present windows/ overview seem super slow )

Could a middle ground be achieved on this ?

Thanks !

Interesting, I wonder if another factor is at play or causing the scaling to be wrong in cases. On my system and liveCD tests, the merged changes to duration and easing cause the WindowHeap transitions to match every other effect, when they didn't before. Even the old duration of 300ms is too quick. 

I just spun up a new local user with no config, tried plus and minus 2 ticks on the global Animation Speed slider, and compared the Overview and Desktop Grid against the open/close Window Animations (Fade, Glide, Scale) and Minimize effects, they still match up for me and look very consistent. Even extremes on the scale match up, and i'm honestly wondering why the scale is so large as the center 5 ticks are the most distinct.

Could something in config be overriding the duration and throwing things off on some environments but not all? For instance, I removed this line in my config a year or so ago (around 5.23 release when things regressed) to fix the issue in the title: https://bbs.archlinux.org/viewtopic.php?id=263845. 
It makes me wonder if a similar thing is occurring with the Windowheap effects for some users, possibly even the systems that 400ms look good on (liveCD though..) I've also tested the durations with a 60hz laptop while on a trip this last week, to rule out higher refresh displays being an edge case.

> Interesting, I wonder if another factor is at play or causing the scaling to be wrong in cases. On my system and liveCD tests, the merged changes to duration and easing cause the WindowHeap transitions to match every other effect, when they didn't before. Even the old duration of 300ms is too quick. 

Its strange, here it was "on par" with other effects, which I then used a 1.4 animation factor ( one tick just to the left of default ).

> I just spun up a new local user with no config, tried plus and minus 2 ticks on the global Animation Speed slider, and compared the Overview and Desktop Grid against the open/close Window Animations (Fade, Glide, Scale) and Minimize effects, they still match up for me and look very consistent. Even extremes on the scale match up, and i'm honestly wondering why the scale is so large as the center 5 ticks are the most distinct.

Yes, i agree, the extreme values are way ... extreme :) If Nate has no issue, I could supply a patch to make it less "extreme" and more granular.
Its extremely weird, because the other effects are all around 150ms~200ms. even old present windows. And here is very very noticeable.

> Could something in config be overriding the duration and throwing things off on some environments but not all? For instance, I removed this line in my config a year or so ago (around 5.23 release when things regressed) to fix the issue in the title: https://bbs.archlinux.org/viewtopic.php?id=263845. 
> It makes me wonder if a similar thing is occurring with the Windowheap effects for some users, possibly even the systems that 400ms look good on (liveCD though..) I've also tested the durations with a 60hz laptop while on a trip this last week, to rule out higher refresh displays being an edge case.

I can try a kde neon live cd in the weekend or earlier if I can. But that setting is correct here. I tend to keep an eye on it, because there was a bug that used to reset it, which David Edmundson fixed. ( he also fixed other bugs, like this one: https://invent.kde.org/plasma/kwin/-/commit/0bb3eb2baf5b0a4c0aacbe23bf55c47c0a2c39fd ).


Just to clear one possible issue, you are also using kde git version, correct?
Also as a workaround, the slide/glide effect allow to specify the duration. Overriding it to 400 makes it more similar in timings to the overview/present windows now.

So something weird is happening here... I don't know if its not my system at fault, but I checked the kwinrc variable (it should NOT have one) and the kdeglobals one (which can actually be a custom number if one edits it manually).

(In reply to Alexandre Pereira from comment #12)
Alexandre, may I ask how you have perceived the speed of the old implementation of Present Windows (pre-Overview) until Plasma 5.24? Could you test with a live CD? In my perception, this new values are just a touch slower than the old, 300 ms feels just a bit closer to my eye. But like my whole bug report and the Reddit thread with dozens of upvotes found, 200 ms is definitely way too fast.
If you have used it like an Alt + Tab replacement, maybe look into the Alt + Tab window switcher settings, there is a grid layout you can chose. Present Windows, Overview and the actual Grid should have another speed with more elegance, signaling also your current window positions. That’s how this effect series worked since Plasma 4, Compiz and on their origins in OS X. Plasma 5.25’s speeds just were a shortsighted fault of the reimplemetation.

Hi,

> Alexandre, may I ask how you have perceived the speed of the old implementation of Present Windows (pre-Overview) until Plasma 5.24? 

The previous speed of Present Windows were fine, and it was when I switched to it as an alt tab replacement. I also checked the code: https://invent.kde.org/plasma/kwin/-/blob/v5.23.0/src/effects/presentwindows/presentwindows.cpp#L164

> Could you test with a live CD? In my perception, this new values are just a touch slower than the old, 300 ms feels just a bit closer to my eye. But like my whole bug report and the Reddit thread with dozens of upvotes found, 200 ms is definitely way too fast.

I will test a live iso later on. Like I said on my previous comment, I use the 1 tick slider speed anim to the left, which makes ALL animations smooth and consistent. Overview seems smooth, but now noticeable slow, and others super fast. Also, the speed can be related to the bug I mentioned on the previous commit, when it was changed from kwinrc to kdeglobals, and the speed was reset (making it faster to those that had a slower speed factor on kwinrc. I am speculating here, could be, probably isn't).


> If you have used it like an Alt + Tab replacement, maybe look into the Alt + Tab window switcher settings, there is a grid layout you can chose. 

hum... I actually prefer the present windows/overview effect to the grid layout, but I know the effect you mention, since I use the small grid as alt tab. I just don't like alt tab as much as I prefer to see all windows scaled on the screen.


> Present Windows, Overview and the actual Grid should have another speed with more elegance, signaling also your current window positions. That’s how this effect series worked since Plasma 4, Compiz and on their origins in OS X. Plasma 5.25’s speeds just were a shortsighted fault of the reimplemetation.

I don't think 5.25's speeds are faster. Looking at the code, they are slower. But in my mind, some effects shouldn't have more "elegance" than others, they all should have elegance (especially no frame skipping). That is why, again, I used the 1.4 factor, which would probably put the timings around 300ms from the 200ms (and with it, all the effects were buttery smooth).

Maybe 300ms is a good middle ground, if you also feel it is a touch slower. But as to how it should be, that isn't for me to say, nor I am part of the VDG nor a "usability expert". If the goal is to have some effects fast and some slow, and I am the only one with an issue to it, then nevermind, I will adapt to it some way.


Thanks!

> Just to clear one possible issue, you are also using kde git version, correct?
Yes, I use kdesrc-build against master branch for testing, while my system KDE is 5.25.4 release. My test prep is setting Desktop Grid to Custom layout for 2x2 grid with 4 virtual desktops, nothing else changed from defaults aside from global animation slider while testing.

BTW, it doesn't look like the merge to change the duration has made it into KDE Neon just yet, my eyes noticed on a fresh boot, and the build logs match up (neon-testing-20220809-1823.iso while the commit and build for kwin went in on 8/10 via https://build.neon.kde.org/). Next one should have this change, I'm looking forward to testing it from iso too. 

>Yes, i agree, the extreme values are way ... extreme :) If Nate has no issue, I could supply a patch to make it less "extreme" and more granular.
I think this is an excellent idea, simplifies config in a good way, and wouldn't be too hard to implement. It's hard to think of a use case that would desire the outer edges of the global slider, a default center and two or three ticks to each side seems much more reasonable. A new merge request for enhancement would be the best way to move that forward.

(In reply to Alexandre Pereira from comment #16)
> I don't think 5.25's speeds are faster. Looking at the code, they are
> slower. 

That’s the big misunderstanding here and probably why this bug report was closed so overhasty: The code is deceptive in this case. There was something altered somewhere else, making the values run faster or whatnot, I don’t know. But 5.25 speeds were definitely extremely accelerated. You will see it in comparison to an older release.

> That’s the big misunderstanding here and probably why this bug report was closed so overhasty: The code is deceptive in this case. There was something altered somewhere else, making the values run faster or whatnot, I don’t know. But 5.25 speeds were definitely extremely accelerated. You will see it in comparison to an older release.


I am really starting to think that the speeds in 5.25 became faster because of the AnimationDurationFactor (the speed slider) got moved into kdeglobals instead of kwinrc. I didn't notice any speed up from 5.24 to 5.25 ( and since I have been running git version for years now, I would have noticed it just as I noticed this change ). See bug which was just "recently" fixed: https://bugs.kde.org/show_bug.cgi?id=431259

By the way ... was the bug report closed overhasty? I thought it was closed because of the commit.

Anyway.... i guess I reported my findings (I will test a live neon iso on the weekend), maybe let more users check it out on the 5.26 release and see if they like it. maybe I am the odd one here, using the present windows effect too much.

Thanks for your time ! :)

(In reply to Alexandre Pereira from comment #19)

> By the way ... was the bug report closed overhasty? I thought it was closed
> because of the commit.

Nah, Nate has closed this one before as RESOLVED INTENTIONAL -.-

> I am really starting to think that the speeds in 5.25 became faster because
> of the AnimationDurationFactor (the speed slider) got moved into kdeglobals
> instead of kwinrc. I didn't notice any speed up from 5.24 to 5.25

I'm not sure this is the case: the Overview effect had it's 200ms value set early on in development and the faster transitions were evident in the 5.24 beta compared to the old Grid in that release. 
5.25 brought the new QML Desktop Grid using that shared code, so it inherited the same speed discrepancy.

>maybe let more users check it out on the 5.26 release and see if they like it.

I am grateful this is getting more community feedback now before it ends up in a wider release, because there may still be an underlying issue. 
I'm wondering if these QML effects (all three) are converting or scaling the values unintentionally, or via a lower level portion of Kwin

Hey all! I've tested using neon-testing-20220816-1836.iso and found some things. The changes to the Windowheap duration are there and match up precisely with the rest of Kwin on my desktop and laptop at default config. To note, my desktop has AMDGPU and laptop has a basic Intel chip, but neither GPU or their driver made a difference in Kwin... until I started playing with Vsync:

Bypassing Vsync with env variables seems to cause at least one effect (the older Slide Back) to animate at the unlocked rate. It's only *slightly* faster and much less noticeable on the embedded Intel (~50-60fps), while it's close to instant and horrible on the AMD desktop (Kwin FPS meter reports 144 but seems like 300+fps on that effect). The new Windowheap effects (and 9 out of 10 other effects I tried like Minimize/Open/Close) are not affected by this, and respect the duration regardless of sync/refresh rate. 

I narrowed down this Vsync variable for testing, and can replicate the behavior to a T by logging in again after setting and enabling Slide Back. Reloading plasmashell + kwin_x11 in the same session doesn't apply it, only a full logoff/logon:

echo "export KWIN_X11_NO_SYNC_TO_VBLANK=1" > $HOME/.config/plasma-workspace/env/vsync.sh

Not sure yet which all effects are affected, or if other vsync parameters could cause others to be thrown off, but it's evident some portion of Kwin may be tied to Vsync/refresh rate and indirectly touching durations/timings. I'm interested in digging deeper and finding out what's going on in detail. 

How does this factor in with y'alls setups and animations? Vsync on or off in your day-to-day, and does it make a difference if you toggle? I've always set Vsync on using xorg.conf (TearFree in AMDGPU driver and ForceFullCompositionPipeline in Nvidia for years previous), but i'm sure hundreds if not thousands of users have a vsync preference that this might affect.