Bug 493940

Created attachment 174303 [details]
stuck animation.png Screenshot of the frozen animation (Prt sc)

SUMMARY
When VRR is used on the desktop by setting adaptive sync to "always" some animations can get stuck before completing. Triggering some repaints (like moving mouse, another animation triggering etc.) instantly unfreezes the animation.

It is similar to https://bugs.kde.org/show_bug.cgi?id=487480 but not the same, as there the animations get stuck but don't unfreeze instantly when mouse is moved, but rather seem to fix after some time. Maybe this is some remaining error in the same area of code.

This bug might contribute to other bugs (such as #489050 or #492555) about performance being worse, as during normal use this appears more like a stutter (since defocusing windows, ongoing videos or mouse movement unfreezes the animation it gets stuck only briefly).

STEPS TO REPRODUCE
1. Set adaptive sync to always
2. make sure to not have open windows (the defocus animation unfreezes the animations making it hard to see, looks more like some stutter)
2. click the "show hidden icons" arrow in the taskbar (easiest to reproduce for me, works with more animations such as clicking the application launcher or opening yakuake but might be more difficult to see or trigger).
3. don't move mouse or have something triggering repaints (even on other screens).

OBSERVED RESULT
Animation gets stuck partway consistently, see image and recordings

EXPECTED RESULT
Animation is smooth as butter and runs on highest frame rate supported by the screen.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Tumbleweed, kernel 6.11.0
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
Only tested on laptops with dual gpus (iGPU, dGPU). I can trigger this equally consistently (always) on both a amd+amd and a intel+nvidia (proprietary driver) system.

since vrr => wayland

The image "stuck animation.png" displays where the "show more" animation gets stuck. Its always at the end (often if not always the same frame), and can stay like that until something unfreezes it (like moving mouse). Image from amd+amd laptop.

IMPORTANT ADDITIONAL INFORMATION
Recording the issue with spectacle is difficult, as it seems the frames spectacle is recording are different from what the screen is displaying, and very seldom catches the frozen frame - it seems the recording also freezes/pauses during the freeze.

"adaptive sync = always - MOBILE.webm" is recorded with my phone and shows the bug in action. Notice every opening freezes, and stays so until I interact with it or move the mouse. This video is filmed at the same time as the spectacle recording (see below).

"adaptive sync = always - spectacle.webm" shows the spectacle recording during the bug being reproduced. Notice the frozen animation is not visible, and for example the longish pause during the first freeze (before i touch the window) seems missing, compare with the phone recording (also see the pulsating of the recording button).

"expected (adaptive sync = automatic).webm" shows how it behaves with "adaptive sync = automatic" (vrr off) and is what the expected result is.