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.
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.
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
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
*** Bug 422844 has been marked as a duplicate of this bug. ***
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