Created attachment 152298 [details] Patch to demonstrate all three animation duration values at once SUMMARY WindowHeap effects (Desktop Grid, Overview, Windowview) do not seem consistent with the rest of KWin's existing effects. This was previously reported in https://bugs.kde.org/show_bug.cgi?id=455521 with many notes in the comments, I'll reiterate that this is the exact same issue as described in the other report. It's been suggested that this may be an issue only at fast global durations: https://invent.kde.org/plasma/kwin/-/merge_requests/2948#note_527556, but I do not believe this is the case as I can dial the global slider to the left and observe the discrepancy even at slower durations. While I can't be 100% sure, this does not seem to be an issue with compositor performance, framerate, screen painting, or anything outside of simple duration timings/units. I'm raising this bug to discuss this discrepancy and request feedback from more people. There are surely more users and developers of the Desktop Grid that noticed the animation speeds changing and know their old preference. Could there be a lower-level function or logic unintentionally scaling the values? I've also attached a patch for demonstration that will raise the Desktop Grid's duration to 400ms and lower the Overview to 200ms, while leaving Windowview at the current 300ms. All three effects can then be cycled between and compared with the rest of the Kwin effects. NOTES The effect can be observed most easily on releases 5.24-5.25, where these effects have a hardcoded duration value of 200ms. This duration was chosen during development based on being a multiple of the standard Kirigami units, so Overview and Windowview (replaced Present Windows) have used this duration since their inception. The Desktop Grid was formerly keyed at 300ms, to note. I noticed in the 5.24 beta that Overview (WindowHeap) seemed much too fast compared to the existing Grid+Present Windows. When 5.24 was released, the Overview effect's speed was still the same (too fast), but as a user of the Desktop Grid, I was unbothered at the time. 5.25 switched the Grid over to the new WindowHeap system, and suddenly the familiar Desktop Grid was "too fast" as a result, using the same global animation duration value as I always had. I use the Desktop Grid about every 5 minutes at work, often enough for a mouse bind, so the effect was effectively broken for me. My first attempt at a fix was simply to scale the value `effect.animationDuration * 2` in the Desktop Grid's new QML source. This restored the Grid to it's former feel without any other changes, but of course did not affect the Overview and Windowview effects, and would not have been the right fix. I tried other scales in that early test without knowing which value they were operating on yet: * 1.2 (240ms), *1.5 (300), * 1.8 (360), only * 2 (400) felt correct and consistent. In this semi-patched state, I bound these three effects to adjacent hotkeys and would cycle between them one by one to ensure I wasn't going nutty. Desktop Grid would perfectly match while Overview and Windowview would not. The effects are always buttery smooth on 144hz screens when using default global KCM Animation values, or plus/minus two ticks. They are simply faster than the other effects by comparison (Open/Close, Minimize/Restore, Virtual Desktop Slide, Slide Back). I went back to the source after a few weeks of daily driver usage, and found `setAnimationDuration(animationTime(200));` in each effect's source, increasing it to 400 had the same effect as my previous * 2 scale attempt and appears to be the right place to set this value. I researched further (full IDE+debugger set up by now) and found that the earlier incarnation of the Grid ran at a 300ms duration. However, even 300ms is too fast, 400ms (or * 2) feels exactly like the pre-5.24 effects did. 400ms seems like an extreme value considering the old value of 300ms, but it matches right up. I opened a MR with my findings, and it was considered and merged: https://invent.kde.org/plasma/kwin/-/merge_requests/2781 We also uncovered improvements to the easing effects in the new Grid, and I tested these against the old 300ms value to be sure, but they were not the root cause of the discrepancy: Overview and Windowview already had the correct easing. Once the change was in master and the neon testing ISO, I ran it on all my machines for a final check, and was able to comment out a patch from my personal build. However, when building from latest master a few days ago to test the new window placement improvments, I noticed right away that the change in https://invent.kde.org/plasma/kwin/-/merge_requests/2948 has re-introduced the inconsistency by lowering the duration to 300ms. At this point, I really did think that I was going nutty, and forced myself to use the 300ms system for a few hours. It did not feel not right, and I ended up changing it back for my daily use. STEPS TO REPRODUCE 1. Grab neon-testing-20220920-1824.iso (and optionally Kubuntu 21.10 or similar with 5.22 for the last functional version of the old desktop grid) 2. Use the System Settings KCM to adjust the Animation Duration up and down, and to set basic configuration for Desktop Grid+Virtual Desktops. 3. Engage the Overview (Meta+W), the Desktop Grid (Ctrl+F8), and Windowview (Ctrl+F10) and compare to other effects such as Virtual Desktop slide. OBSERVED RESULT The WindowView effect transitions start and stop faster than the rest of the Kwin effects. EXPECTED RESULT WindowView effects should match the rest of the system and feel consistent. SOFTWARE/OS VERSIONS Linux: Arch Linux 5.19.9 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION I'm attempting a screen recording with OBS but can't record at an acceptable framerate without configuring AMD hardware encoding first.
KWin effects are currently all over the place in terms of duration; that's one of the problems we're trying to fix by hardcoding everything to a 200ms duration (the value of Kirigami.Durations.longDuration), which will make everything consistent. Unfortunately 200ms was perceived as too fast by a lot of people. So we tried 400, and other people said it was too slow. Now we're at 300, and you're saying it's not consistent. We can't seem to please all of these groups of people at once. I strongly suspect that most complaints actually boil down to the animation's initial delay before it begins and its choppiness. If we fix those, probably all animation durations will feel better and we can get away with 200ms to be consistent with other 200ms animations through the rest of the system. If not, another option is that the problem is the animations' easing curve, not their duration.
(In reply to Nate Graham from comment #1) > I strongly suspect that most complaints actually boil down to the > animation's initial delay before it begins and its choppiness. I really must record my screen to demonstrate what I mean with this bug report. There's no perceivable delay on my end from hotkey activation to when the animation begins, for any effects, and they are all smooth. Even on the faster end of the global slider, I don't think any frames are being dropped, etc, unless there is something behind the scenes. Is this delay you mentioned a known bug, or necessary for some animations to work properly? > If not, another option is that the problem is the animations' easing curve, > not their duration. I tested with several curves detailed under https://doc.qt.io/qt-6/qml-qtquick-animator.html when we looked at them under the first MR, and against the old grid's 300ms value at least once. I'm not sure the easing is at fault. >KWin effects are currently all over the place in terms of duration; that's one of the problems we're trying to fix by hardcoding everything to >a 200ms duration (the value of Kirigami.Durations.longDuration), which will make everything consistent. > If we fix those, probably all animation durations will feel better and we can get away > with 200ms to be consistent with other 200ms animations through the rest of > the system. Of course we want consistent animations, but are all other Kwin effects are using 200ms already? Something is not right then. Could it be something mishandling `AnimationDurationFactor=` from kdegloblals? I'm inspecting as we speak and seeing longer float values being written that I did not expect. The entire scale as I see it, could those long floats be a problem? I'm going to test playing with these values now that I know about them. Instant +8: 0 +7: 0.08838834764831843 +6: 0.125 +5: 0.17677669529663687 +4: 0.25 +3: 0.35355339059327373 +2: 0.5 +1: 0.7071067811865475 Default: no written value for AnimationDurationFactor -1: 1.414213562373095 -2: 2 -3: 2.82842712474619 -4: 4 -5: 5.65685424949238 -6: 8 -7: 11.31370849898476 -8: 16 Slow
> Is this delay you mentioned a known bug, or necessary for some animations to work properly? > It's a bug; see Bug 455780. It's 100% reproducible for me. > Of course we want consistent animations, but are all other Kwin effects are using 200ms already? No, that's the problem. Like I said, they're currently all over the place. There is no standardization. They have differing default durations and many durations are user-customizable, too. As a result, the user experiences KWin animations as having no consistency at all. > The entire scale as I see it, could those long floats be a problem? Your numbers look correct to me--or at least, expected.
(In reply to Nate Graham from comment #3) > It's a bug; see Bug 455780. It's 100% reproducible for me. Interestingly I can't reproduce this bug on X11 or Wayland, on desktop nor laptop (laptop with KDE Neon testing 9/20). I'd say it's unrelated to this report though either way. > No, that's the problem. Like I said, they're currently all over the place. > There is no standardization. They have differing default durations and many > durations are user-customizable, too. As a result, the user experiences KWin > animations as having no consistency at all. I suppose this is what the issue boils down to. Is there an ongoing effort or posted task to unify every effect's duration to the standard global scale, just all at once? If all that needs done is comparing+adjusting values and testing each item in src/effect against the standard, that's something I want to try and help with.
There is no ongoing effort I'm aware of. Please do feel free to start one! Even if it's as simple as: - change all the effects' default animation durations (configurable or not) to 200ms (longDuration) or 400ms (veryLongDuration), whichever one feels more appropriate and is closer to its existing value - internally scale that value by the global animation duration multiplier
(In reply to Nate Graham from comment #5) > There is no ongoing effort I'm aware of. Please do feel free to start one! > Even if it's as simple as: > - change all the effects' default animation durations (configurable or not) > to 200ms (longDuration) or 400ms (veryLongDuration), whichever one feels > more appropriate and is closer to its existing value > - internally scale that value by the global animation duration multiplier Exactly what I had in mind, and hopefully as simple as that, considering the scaling that some effects may need. I'll walk down the effects tree and see what I can find :)
Fantastic! This should make a big difference.
Git commit 028dd552cfb9d826b40b9620d869c98d2aa3dca3 by Niccolò Venerandi. Committed on 25/09/2023 at 13:14. Pushed by niccolove into branch 'master'. Merge desktop grid and overview together with a new three-state design Merges the desktop grid and overview effects together in a new three-state one; you can switch between them with a certain shortcut or gesture, and you can also still access either the desktop grid or overview directly. Default shortcuts are also updated to be Meta+G for Grid, Meta+W for Overview, Meta+Tab to switch between the three states and Meta+Shift+Tab to cycle in the opposite direction. Related: bug 474044, bug 460661, bug 460774, bug 456572, bug 449601, bug 450262, bug 449801, bug 461510, bug 463886, bug 459754, bug 459749, bug 459748 FIXED-IN: 6.0 M +2 -0 CMakeLists.txt A +7 -0 kconf_update/CMakeLists.txt A +20 -0 kconf_update/kwin-6.0-overview-activities-shortcuts.py A +11 -0 kconf_update/kwin.upd M +16 -3 src/libkwineffects/effecttogglablestate.cpp M +3 -1 src/libkwineffects/effecttogglablestate.h M +0 -1 src/plugins/CMakeLists.txt D +0 -49 src/plugins/desktopgrid/CMakeLists.txt D +0 -127 src/plugins/desktopgrid/desktopgrid_config.cpp D +0 -48 src/plugins/desktopgrid/desktopgrid_config.h D +0 -206 src/plugins/desktopgrid/desktopgrid_config.ui D +0 -32 src/plugins/desktopgrid/desktopgridconfig.kcfg D +0 -9 src/plugins/desktopgrid/desktopgridconfig.kcfgc D +0 -250 src/plugins/desktopgrid/desktopgrideffect.cpp D +0 -99 src/plugins/desktopgrid/desktopgrideffect.h D +0 -18 src/plugins/desktopgrid/main.cpp D +0 -92 src/plugins/desktopgrid/metadata.json D +0 -306 src/plugins/desktopgrid/qml/DesktopView.qml D +0 -328 src/plugins/desktopgrid/qml/main.qml M +27 -6 src/plugins/overview/kcm/overvieweffectkcm.cpp M +15 -1 src/plugins/overview/kcm/overvieweffectkcm.ui M +3 -0 src/plugins/overview/overviewconfig.kcfg M +229 -24 src/plugins/overview/overvieweffect.cpp M +37 -16 src/plugins/overview/overvieweffect.h M +44 -36 src/plugins/overview/qml/DesktopBar.qml M +541 -193 src/plugins/overview/qml/main.qml M +24 -18 src/plugins/private/qml/WindowHeapDelegate.qml M +1 -0 src/plugins/windowview/qml/main.qml M +0 -2 src/plugins/windowview/windowvieweffect.cpp https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d2aa3dca3