Bug 425856 - Kwin FPS inconsistent after kwin is suspended
Summary: Kwin FPS inconsistent after kwin is suspended
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: performance (show other bugs)
Version: 5.19.4
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 422844 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-08-27 05:50 UTC by odzinic
Modified: 2024-06-07 17:07 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description odzinic 2020-08-27 05:50:28 UTC
SUMMARY
When kwin gets suspended and resumed through either manual suspension (ctrl+shift+F12), application block composition or suspending the pc, the FPS becomes very unstable. For example, playing a video or highlighting icons on the desktop will cause the FPS to drop from 100 to 60 (which is the lowest refresh rate I have in my monitor setup) until I pause the video or stop highlighting the desktop. The FPS will then go back up to 100.

STEPS TO REPRODUCE
1. Suspend and resume kwin
2. Play a video/animation/drag around a highlight box on your desktop

OBSERVED RESULT
FPS is not stable and drops down to the lowest refresh rate in the system (in this example 60 fps with a 144hz/60hz monitor setup)

EXPECTED RESULT
FPS stays stable

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.8.3-2-MANJARO
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz
Memory: 15.6 GiB of RAM
Graphics Processor: GeForce GTX 1080 Ti/PCIe/SSE2

ADDITIONAL INFORMATION

The issue goes away once I make my icon-only task manager appear from auto-hide or I restart kwin. This fixes it when kwin was manually suspended, automatically suspended or suspended by a short PC suspend. I will try testing this with an overnight PC suspend as well. I have tested this out on the Nvidia 440 and 450 drivers and it occurs on both.
Comment 1 odzinic 2020-08-27 15:30:58 UTC
I think I may have found the cause of this issue. I noticed that if I had an application open but minimized, simply hovering over the task manager would not fix the issue. What would fix the issue was unminimizing the window. If all the application I had open were visible on the desktop when suspending/resuming kwin, the fps drops would not occur and my fps would stay at a constant 100. If I suspended/resumed with minimized applications, the issue would occur until all the applications were unminimized. This led me to believe that the issue must have been caused by the thumbnails being generated by the compositor. My "Keep window thumbnails" setting was originally set to "Only for shown windows" but after switching it to "Always" I was no longer experiencing this issue. I have tested it with manually suspending/resuming kwin, having an application block compositing and then closing it and suspending my pc. Issue did not occur a single time.
Comment 2 Christian Wichmann Moesgaard 2021-07-25 10:22:31 UTC
I'm affected by this as well on Pop!_OS 21.04, based on Debian.

It kept getting worse whenever I suspended and unsuspended Kwin due to running games. It started perfectly smooth at 60, then it went down to 30, then 20, then 15, then 12, then 10.

Like with odzinic, setting it to always keep thumbnails immediately fixed it.

Operating system: Pop!_OS 21.04
KDE Plasma version: 5.21.4
KDE Frameworks version: 5.80.0
Qt version: 5.15.2
Kernel version: 5.11.0-7620-generic
OS type: 64-bit
Graphics platform: X11

Processor: AMD Ryzen 9 5900X
Memory: 31.3 GiB (???)
GPU: NVIDIA GeForce RTX 3080
Comment 3 Andreas Kilgus 2021-11-04 21:47:15 UTC
For a long time I had been wondering why my desktop behaved laggy with compositing enabled (disabling compositing though gave me a smooth desktop experience). It was not always the case after a restart of the machine but every time after suspending or a game having disabled the compositor temporarily. I changed drivers, OpenGL versions, … to no avail. But indeed - changing the compositor setting to keep window thumbnails "always" (neither "never" nor "only visible") removes the lag immediately.

Operating System: openSUSE Leap 15.2
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.15-lp153.2.g3416a5a-default (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz
Memory: 15.6 GiB of RAM
Graphics Processor: AMD BONAIRE
Comment 4 David Edmundson 2024-06-04 10:28:21 UTC
*** Bug 422844 has been marked as a duplicate of this bug. ***
Comment 5 Zamundaaa 2024-06-07 17:07:58 UTC
Repaint scheduling has been changed a bunch with Plasma 6, so I'm reasonably certain this is fixed. If you can still reproduce this on Plasma 6, just reopen this