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.
Created attachment 174304 [details] adaptive sync = always - MOBILE.webm A recording of the bug with my phone. This shows the bug clearly and consistently.
Created attachment 174305 [details] adaptivesync=always - spectacle.webm spectacle recording failing to show the bug. Taken at the same time as the mobile recording
Created attachment 174306 [details] expected (adaptivesync=automatic).webm Shows how it should look (lower framerate since spectacle recording)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6556
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6557
Git commit 371879a9f9c22a36d987e7a9c61bc4f8583c1f82 by Xaver Hugl. Committed on 02/10/2024 at 15:03. Pushed by zamundaaa into branch 'master'. core/renderloop: only delay scheduling repaints while vrr is active, don't entirely drop them Otherwise, the following situation can happen - effect tries to schedule a repaint, which gets ignored because the window has at least 30fps - the window stops updating - the effect's last frame is stuck on the screen, until something else triggers a repaint M +7 -0 src/core/renderloop.cpp M +2 -0 src/core/renderloop_p.h https://invent.kde.org/plasma/kwin/-/commit/371879a9f9c22a36d987e7a9c61bc4f8583c1f82
Git commit f490e1fee7c38bf0613d80a065db6028e58c2977 by Xaver Hugl. Committed on 02/10/2024 at 15:41. Pushed by zamundaaa into branch 'Plasma/6.2'. core/renderloop: only delay scheduling repaints while vrr is active, don't entirely drop them Otherwise, the following situation can happen - effect tries to schedule a repaint, which gets ignored because the window has at least 30fps - the window stops updating - the effect's last frame is stuck on the screen, until something else triggers a repaint (cherry picked from commit 371879a9f9c22a36d987e7a9c61bc4f8583c1f82) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +7 -0 src/core/renderloop.cpp M +2 -0 src/core/renderloop_p.h https://invent.kde.org/plasma/kwin/-/commit/f490e1fee7c38bf0613d80a065db6028e58c2977
Wow you guys are awesome! Thank you! I just found that I might have missed an existing bug for this: https://bugs.kde.org/show_bug.cgi?id=483429 To me it looks like my bug report is a duplicate, should I mark it as such now when its resolved?
*** Bug 483429 has been marked as a duplicate of this bug. ***