Bug 493940

Summary: Adaptive sync = always causes animations to get stuck
Product: [Plasma] kwin Reporter: Max <max>
Component: performanceAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: leonardo, nate, xaver.hugl
Priority: NOR    
Version: 6.1.5   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 6.2.0
Sentry Crash Report:
Attachments: stuck animation.png Screenshot of the frozen animation (Prt sc)
adaptive sync = always - MOBILE.webm A recording of the bug with my phone. This shows the bug clearly and consistently.
adaptivesync=always - spectacle.webm spectacle recording failing to show the bug. Taken at the same time as the mobile recording
expected (adaptivesync=automatic).webm Shows how it should look (lower framerate since spectacle recording)

Description Max 2024-10-01 20:01:38 UTC
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.
Comment 1 Max 2024-10-01 20:03:10 UTC
Created attachment 174304 [details]
adaptive sync = always - MOBILE.webm
A recording of the bug with my phone. This shows the bug clearly and consistently.
Comment 2 Max 2024-10-01 20:04:36 UTC
Created attachment 174305 [details]
adaptivesync=always - spectacle.webm spectacle recording failing to show the bug. Taken at the same time as the mobile recording
Comment 3 Max 2024-10-01 20:07:31 UTC
Created attachment 174306 [details]
expected (adaptivesync=automatic).webm Shows how it should look (lower framerate since spectacle recording)
Comment 4 Bug Janitor Service 2024-10-02 15:04:18 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6556
Comment 5 Bug Janitor Service 2024-10-02 15:41:49 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6557
Comment 6 Zamundaaa 2024-10-02 15:49:25 UTC
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
Comment 7 Zamundaaa 2024-10-02 15:54:48 UTC
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
Comment 8 Max 2024-10-04 09:51:50 UTC
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?
Comment 9 Zamundaaa 2024-10-04 11:24:54 UTC
*** Bug 483429 has been marked as a duplicate of this bug. ***