https://bugs.kde.org/show_bug.cgi?id=493940

            Bug ID: 493940
           Summary: Adaptive sync = always causes animations to get stuck
    Classification: Plasma
           Product: kwin
           Version: 6.1.5
          Platform: openSUSE
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: performance
          Assignee: kwin-bugs-n...@kde.org
          Reporter: m...@eterkludd.se
  Target Milestone: ---

Created attachment 174303
  --> https://bugs.kde.org/attachment.cgi?id=174303&action=edit
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to