As you can see in these videos, displaying window thumbnails takes a long time and almost utilizes a bit high CPU, and causes lag in the entire desktop; If you pay attention to the movement of the mouse cursor(First video) and how to play the video(Second video), you can see the lag clearly, Also as you can see at the end of the second video, this problem occurs only in Task Manager(Only in Wayland session) and "Window switching" effect works fine. This problem may not be detectable on powerful systems, but it is very annoying in old and low-end systems like my old laptop. Video 1: https://youtu.be/Vx8WeRMudso Video 2: https://youtu.be/gP3QTwwPxdU System: Host: localhost.localdomain Kernel: 5.16.4-1-default x86_64 bits: 64 compiler: gcc v: 11.2.1 Desktop: KDE Plasma 5.24.80 tk: Qt 5.15.2 wm: kwin_wayland dm: SDDM Distro: openSUSE Tumbleweed 20220206 CPU: Info: Dual Core model: Intel Core2 Duo T6670 bits: 64 type: MCP arch: Penryn rev: A cache: L2: 2 MiB flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx bogomips: 8771 Speed: 1215 MHz min/max: 1200/2201 MHz boost: enabled Core speeds (MHz): 1: 1215 2: 1552 Graphics: Device-1: Intel Mobile 4 Series Integrated Graphics vendor: Sony driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:2a42 Device-2: Ricoh Sony Vaio Integrated Webcam type: USB driver: uvcvideo bus-ID: 2-2:2 chip-ID: 05ca:18b3 Display: wayland server: SUSE LINUX 1.21.1.3 compositor: kwin_wayland driver: loaded: modesetting unloaded: fbdev,vesa alternate: intel resolution: 1280x800~60Hz s-dpi: 96 OpenGL: renderer: Mesa Mobile Intel GM45 Express (CTG) v: 2.1 Mesa 22.1.0-devel-git-e2cd0c3a direct render: Yes
Can reproduce on my system. Even audio becomes choppy while I repeatedly hover over the entries of the task manager. Operating System: Arch Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Graphics Platform: Wayland
Should provide an option to disable previews and only show app icons on Wayland.
Created attachment 149539 [details] System Journal Log This problem seems to have been fixed in my machine(openSUSE Krypton repo 22-06-05), But I noticed, that if I use the window-thumbnail repeatedly(As I did in the videos), causing massive memory leaks in the kwin_wayland process, especially once a video is playing(MPV(Wayland), VLC(Xwayland) and Chrome(Wayland)) the kwin_wayland memory usage rising up to 1.4GB and finally, the Pipewire completely stop(includes Audio devices and window thumbnail feature) and the attached messages logged on system journal, And then sometimes after a few moments and sometimes when a video is playing, after stopping the video or closing the player, everything goes back to normal and the Pipewire start to working again; And I have no idea if these two issues are related or no, Or is it a plasma problem at all or is it related to the Pipewire? Also, I've never repeatedly used window-thumbnail like this since video recording, and I do not know exactly when this problem started.
On my system, plasmashell leaks memory, see bug 450880
Currently, on Kwin(git-9bb1a440), Pipewire doesn't crash anymore, Also memory leak still occurs, but not in the kwin_wayland, and it seems that memory leaks are now occurring in the graphics stack, because memory consumption of all processes is normal, but every time I use from the window-thumbnail, the amount of available memory decreases significantly(So that eventually all the memory is consumed), Also desktop lag occurs again, and lags are worse than ever before. Also lot of "plasmashell[]: QCoreApplication::postEvent: Unexpected null receiver" and "kwin_wayland[]: kwin_wayland_drm: Could not create drm framebuffer! Invalid argument" warnings are logged in system journal. System Info System: Host: localhost.localdomain Kernel: 5.18.2-1-default arch: x86_64 bits: 64 compiler: gcc v: 12.1.0 Desktop: KDE Plasma v: 5.25.80 tk: Qt v: 5.15.2 wm: kwin_wayland dm: SDDM Distro: openSUSE Tumbleweed 20220611 CPU: Info: dual core model: Intel Core2 Duo T6670 bits: 64 type: MCP arch: Core Yorkfield rev: A cache: L1: 128 KiB L2: 2 MiB Speed (MHz): avg: 1228 high: 1244 min/max: 1200/2201 boost: enabled cores: 1: 1244 2: 1213 bogomips: 8771 Flags: ht lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx Graphics: Device-1: Intel Mobile 4 Series Integrated Graphics vendor: Sony driver: i915 v: kernel ports: active: LVDS-1 empty: DP-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:2a42 Device-2: Ricoh Sony Vaio Integrated Webcam type: USB driver: uvcvideo bus-ID: 7-2:2 chip-ID: 05ca:18b3 Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.2 compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa alternate: intel gpu: i915 display-ID: 0 Monitor-1: LVDS-1 res: 1280x800 size: N/A OpenGL: renderer: Mesa Mobile Intel GM45 Express (CTG) v: 2.1 Mesa 22.2.0-devel-git-5c37320e direct render: Yes
"kwin_wayland[]: kwin_wayland_drm: Could not create drm framebuffer! Invalid argument" this can explain why frame rate drops, not sure what might be causing it. As for high cpu usage, it sounds as if kwin were sharing window thumbnails using shared memory instead of dmabuf, which can affect performance very drastically.
It seems that the "kwin_wayland[]: kwin_wayland_drm: Could not create drm framebuffer! Invalid argument" warnings are related to the https://bugs.kde.org/show_bug.cgi?id=453860 issue because, when building Kwin with https://invent.kde.org/plasma/kwin/-/merge_requests/2483, warnings are disappeared, And other problems still exist with Kwin git-9dbd0c4b.
I updated the system after about two weeks, and the invisible memory leak doesn't occur anymore.
*** Bug 464530 has been marked as a duplicate of this bug. ***
*** Bug 470058 has been marked as a duplicate of this bug. ***
>I updated the system after about two weeks, and the invisible memory leak doesn't occur anymore. So I assume this can be closed? The duplicate reports seems subtly different and reference other commits that are now merged Please reopen if an issue remains.
Wasn't this bug about taskbar/task manager being performance intensive and not about some probably remotely related memory leak? I would connect memory leak with crashing, not with (probably CPU-based) performance intesive desktop lags.