SUMMARY Animation times when toggling the desktop grid / overview or the desktop cube are sometimes almost instantaneous. I am not sure how to reliably reproduce this, but I immediately noticed that after upgrading my system to Plasma 6.6.0 today. It was fine on 6.5.5 and was probably introduced with the removal of the hardcoded 60hz animations, but that is just my guess. I've selected the effects-overview category, but I'm not sure if this belongs here. I've tried testing this with reduced global animation times, but this is even more difficult to reproduce. If it happens, you can see that the animation is playing at a much, much faster speed for a brief moment, until it runs at the regular speed again. It's unfortunately a bit difficult to see since there's also animation easing, but it's definitely there. Considering that the normal animation times are rather short (as they should be), the increased speed thus feels like it's almost instantaneous. STEPS TO REPRODUCE 1. Repeatedly toggle the desktop grid effect 2. 3. OBSERVED RESULT If it happens, the animation time is much, much faster for a short time EXPECTED RESULT The animation time should always be constant (not talking about the animation easing of course) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.6.0 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8838
Note that I am not sure that I see exactly the same issue that you do, but I think that MR should help.
(In reply to Vlad Zahorodnii from comment #2) > Note that I am not sure that I see exactly the same issue that you do, but I think that MR should help. I've applied 9166dbdfa2a5706f3d6b3a30f1e6fc1fe3da3320 from MR 8838 to my KWin build and this has fixed the issue. At least from what I can tell after testing this for more than 5 minutes. Thanks!
Okay thanks for testing
Git commit e187fa5d18af4e6b10e9ead575f5cdf42c2c2473 by Xaver Hugl, on behalf of Vlad Zahorodnii. Committed on 19/02/2026 at 16:08. Pushed by zamundaaa into branch 'master'. Drive our QAnimationDriver fully by presentation timestamps Outputs can have different next presentation timestamps, elapsed() can roll back, which is generally not good for animations. We need to guard the QAnimationDriver against this case. While on this, also make m_offset sync with the first provided presentation timestamp to make calculated delta times more predictable. M +15 -10 src/renderloopdrivenqanimationdriver.cpp M +2 -3 src/renderloopdrivenqanimationdriver.h https://invent.kde.org/plasma/kwin/-/commit/e187fa5d18af4e6b10e9ead575f5cdf42c2c2473
Git commit 40f41b493c09be357131f191656fe1abed68afdc by Vlad Zahorodnii. Committed on 19/02/2026 at 16:48. Pushed by vladz into branch 'Plasma/6.6'. Drive our QAnimationDriver fully by presentation timestamps Outputs can have different next presentation timestamps, elapsed() can roll back, which is generally not good for animations. We need to guard the QAnimationDriver against this case. While on this, also make m_offset sync with the first provided presentation timestamp to make calculated delta times more predictable. (cherry picked from commit e187fa5d18af4e6b10e9ead575f5cdf42c2c2473) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +15 -10 src/renderloopdrivenqanimationdriver.cpp M +2 -3 src/renderloopdrivenqanimationdriver.h https://invent.kde.org/plasma/kwin/-/commit/40f41b493c09be357131f191656fe1abed68afdc