| Summary: | WindowHeap-based effects' opening and closing animations just don't feel right | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Blazer Silving <breakingspell> |
| Component: | effects-window-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | nate, postix |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.25.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=455780 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d2aa3dca3 | Version Fixed In: | 6.0 |
| Sentry Crash Report: | |||
| Attachments: | Patch to demonstrate all three animation duration values at once | ||
|
Description
Blazer Silving
2022-09-21 02:02:33 UTC
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 |