SUMMARY kwin_wayland slows from 60 FPS to ~25 FPS when opening 50-100 windows that overlap (including completely covering each other). I can reproduce this using any Wayland applications, including Firefox and Konsole, and both on the host compositor as well as when launching a plain kwin_wayland instance in a nested window and opening the application windows in there. The FPS drop happens regardless of the KWIN_DRM_DISABLE_TRIPLE_BUFFERING setting, and seems to affect just the monitor that the all the windows reside on: on that monitor dragging any of the windows is very laggy, and the windows update very slowly (choppy scrolling, bad responsiveness). This is particularly problematic for Firefox, since its performance is directly tied to the update rate: loading websites goes from a couple of seconds to over 15 seconds, making usage quite unbearable. Fullscreening a Firefox window also doesn't help. Dragging any of the windows to a second monitor (without a lot of windows on it) restores its performance. Additionally, minimizing all the windows also fixes the situation, kwin goes back to 60 FPS and responsiveness for all remaining windows is restored. If switching Firefox to X11 (XWayland), the FPS drop is greatly reduced (although XWayland is not as smooth in scrolling to begin with). Interestingly, on the host compositor, opening specific windows, such as Chromium, kinfocenter or systemsettings, on the affected monitor fixes all the issues right away. Chromium/kinfocenter/systemsettings stays buttery smooth, and also increases the FPS of all the other Konsole and Firefox windows back to 60 FPS. So as long as one of those windows is located on the same monitor, the performance is as expected, I have no idea why. STEPS TO REPRODUCE 1. (Optionally) open a nested kwin_wayland instance: `kwin_wayland --exit-with-session konsole` 2. Make sure Chromium (or any Chromium-based Wayland-enabled thing probably), kinfocenter and systemsettings aren't running (basically close all other applications) 2. Open Wayland application windows: `for i in $(seq 100); do { konsole & }; done` 3. Interact with the windows, drag them around, resize them etc. OBSERVED RESULT Everything on the affected monitor slows to ~25 FPS, applications are inresponsive and refresh slowly (especially noticeable when scrolling Firefox). EXPECTED RESULT 60 FPS, applications stay responsive and smooth. Open Chromium/kinfocenter/systemsettings on the same monitor to see the desired result in action. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.7.2 Kernel Version: 6.12.8-cb1.0.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8365U CPU @ 1.60GHz Memory: 31,1 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO System Version: ThinkPad T490 3x identical 1920x1200 60 Hz displays with regular timings, also repro'd on the laptop's internal display (1920x1080). 100% scaling. ADDITIONAL INFORMATION I'm working on providing KWIN_LOG_PERFORMANCE_DATA traces. I also tried to `perf record` a nested kwin_wayland session, but that doesn't work for some reason, kwin_wayland just terminates instantly: $ perf record --call-graph dwarf -- kwin_wayland --exit-with-session konsole [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0,001 MB perf.data ] Terminated
Created attachment 177281 [details] KWIN_LOG_PERFORMANCE_DATA render time annotated Here's an annotated run with KWIN_LOG_PERFORMANCE_DATA=1 with 100 konsole instances. As soon as the instances open, the render time jumps to ~50 ms when dragging around a window, until opening systemsettings, after which it drops to a steady 16.67 ms. Closing systemsettings brings back the issue.
Created attachment 177282 [details] KWIN_LOG_PERFORMANCE_DATA raw data
I also tried disabling window shadows for GTK and Qt applications to prevent stacked shadows, but no significant improvement. Additionally, the "Show FPS" desktop effect also shows this issue. For some reason the "Current FPS" is doubled for me (shows 120 by default), but it still drops to ~40-50 (so about ~25 FPS in reality) when the issue occurs.
This CPU and GPU hardware is somewhat modest, but yeah, it shouldn't do that.
After updating to Plasma 6.3.0 I'm not seeing this issue anymore. Even after multiple hibernation cycles Plasma remains very responsive, even with 100+ windows, across all monitors, no matter the specific applications. In fact, Plasma now feels much more responsive in general than ever before, so thanks for the performance work! And no, I wouldn't classify this hardware as modest quite yet, it's all about software optimization :)