SUMMARY Plasmashell seems to cause high CPU use in kwin_x11 and Xorg. Typical CPU use is ~ 25 % kwin_x11, ~ 15% Xorg and ~ 10 % plasmashell. The CPU use continues for several minutes, without user interaction or any screen activity. Doing a 'kill -STOP pid' / 'kill -CONT pid' pause test from a remote shell shows that when either kwin_x11 or Xorg is paused, plasmashell's CPU use continues. When plasmashell is paused, both kwin_x11 and Xorg stop using CPU. It is triggered by switching to another virtual desktop using a shortcut or a touchpad gesture. It's related to the panel. Making the panel visible (it has auto-hide enabled), either by mouse movement or the META key, stops the CPU use. Switching virtual desktops starts it again. Switching virtual desktop using the pager in the panel has no effect on CPU, probably because then the panel is already visible. The panel has start button, (full) task manager, virt. desktop pager, system tray and digital clock. STEPS TO REPRODUCE 1. Have a panel on auto-hide 2. Have 'top' running in a konsole or any other cpu indicator and verify there is no significant CPU use 3. Switch to another virtual desktop and back. 4. Observe double digit CPU use in kwin_x11, plasmashell and Xorg 5. Wait as long as you like. 6. Briefly make the panel visible 7. Observe the CPU use drop. OBSERVED RESULT High CPU use, lasting several minutes. EXPECTED RESULT Brief CPU use, than idle. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.8.10-300.fc40.x86_64 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-7500U CPU @ 2.70GHz Memory: 7,5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 620 Manufacturer: Dell Inc. Product Name: XPS 13 9360 ADDITIONAL INFORMATION - Version 6.0.4 also had this behaviour. Previous 6.0.x were never on this laptop. - It's 100 % repeatable - 'plasmashell --replace' or 'kwin_x11 --replace' have no effect.
Does it happen on Wayland too?
Yes, it does happen with Wayland too. This laptop was installed with Fedora 25 in 2017 and upgraded al the way to Fedora 40 since then. My ~/.config map has a listing as long as your arm, with many items no longer in use. Therefore I created a new clean user account and left as much of the KDE settings on their defaults (except for multiple virtual desktops and an auto-hiding panel populated with the same stuff). The clean user account shows the same behaviour. The double digit CPU use I reported is seen in the 'balanced' power mode. In 'performance' mode CPU use is much lower, more like 7 % (total for three processes). I can imagine that other people, especially those with faster CPU's, don't notice this effect. For instance, on my desktop (same software, but with a Ryzen 9 and a Radeon RX 580 GPU), I can't say for sure whether the effect is there or not. If it is, it's like 0.3 % of extra CPU activitity, but only from Xorg and plasmashell and not from kwin_x11.
How strange! If you turn on the "Show Paint" effect, set a global shortcut for it (I use Meta+Ctrl+Alt+P) and then hit that shortcut to turn it on while the high CPU usage is happening, do you see that the screen is constantly refreshing/repainting? You should see a flicker of color, probably at the same refresh frequency as the screen's refresh rate.
You might be on to something... I do see a flicker. Briefly when I move the mouse cursor, but after a switch to another virtual desktop, the whole screen flickers and keeps on doing that until I bring up the hidden panel. I hoped this also was a method to test my desktop, but I can't get this effect to work there. There is no visible effect from enabling the 'Show Paint' effect. On the laptop though, it's very clear. And headache inducing...
Using the 'Show Paint' effect I was able to narrow it down. Thank you for this tip! It's related to the digital clock in the panel. I have 'Show seconds' set to 'Always'. Setting that to 'Never' stops the continuous screen repaints after virtual desktop switching. Enabling the seconds again brings it back again, but not when I switch desktops right after clicking 'Apply'. I have to close the 'Configure digital clock' window and then switch desktops. Does that make sense to you?
Strike that last comment. It's back while 'Show seconds' is still disabled. I'll have to test more. Won't be today though...
Ok, one more today. It seems like keeping the 'Configure digital clock' window open is what disables this erratic behaviour.
I can now reproduce the issue, thanks. Full steps for me: 1. Have a panel on auto-hide 2. Use the "Show Seconds: Always" setting in that panel's digital clock 3. Turn on Show Paint effect 4. Have `top` running in a konsole or any other cpu indicator and verify there is no significant CPU use 5. Switch to another virtual desktop and back using Meta+Ctrl+[arrow key] 6. Observe Show Paint effect going crazy and double digit CPU use in plasmashell and kwin/xorg (if on X11) 7. Wait as long as you like 6. Briefly make the panel visible 7. Observe Show Paint effect return to normal and the CPU use drops.
Thanks, Nate. I now think I can see this problem on my desktop to. I was looking in the wrong place. Using 'radeontop' in a konsole I can see the exact same pattern on the GPU instead of the CPU.
I did some more testing and I think the steps in comment 8 are incorrect or at least incomplete. - I disabled the "Show seconds' and rebooted my desktop, but the issue was there again right on the first desktop switch after login. - To inhibit the issue I really have to leave the 'Configure digital clock' window open. I can't even Shade it. When I do, the constant repainting starts immediately. No desktop switch needed to trigger it. - However, I can do exactly the same with the configuration window of the Task Manager, the Pager and the Application Launcher. Opening any of them inhibits the issue, shading them triggers it. - The configuration window of Virtual Desktops opens in the System Settings app and this window does not inhibit the issue on desktop switching and does not trigger it on shading. So it's not the digital clock, but something more generic of the panel or the panel widgets and their configuration windows.
It's not a kwin bug.
As a workaround, try removing the pager applet. It seems like animation state management is broken in Qt.
The root cause of the bug: the animation management design is flawed in Qt. First, QSGThreadedRenderLoop is a global, it's shared by all windows. Second, QSGThreadedRenderLoop doesn't care about the window affinity of animations. It means that if you have two QtQuick windows and one is hidden and has a scheduled animation, then the other window will be forced to repaint even though it contains no animations or nothing has been repainted.
s/nothing has been repainted/nothing has been updated/
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2311
upstream bug report: https://bugreports.qt.io/browse/QTBUG-126365
Removing the Pager works as a workaround.
Now with https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2312
You both have your marks on the Pager now, but could a transparent panel (set to 'Translucent' or 'Adaptive') also trigger this issue?
Gentleman (well I hope...), I have removed the Pager from the Panel and set the Panel to 'Opaque', but something is still triggering continuous repaints on some desktop switches. I found this: - Using Ctrl-Meta-[Arrow-key] on the keyboard to switch desktops, there's no trigger to repaints. - Using 'xdotool key crtl-super-Right' (or equivalent for other directions) still triggers repaints. (xdotool is X11 only. Try ydotool on Wayland, but I have no experience with it.) The repaints can still be stopped by making the panel visible. I also don't completely understand the explanation given above, about QSGThreadedRenderLoop. I'm not a developer. I can see how it relates the behaviour between the hidden panel and the configuration windows, but there seems to be no relation to desktop switches. I think there is at least one more contributor to this issue.
There may be multiple causes here, with the pager only being one of them.
Update! Well, actually a very big load of kde plasma updates today. - I can now no longer trigger the repainting using the xdotool command. - When I re-add a pager to the panel, the repainting can still be triggered by a desktop switch. KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1
*** Bug 489328 has been marked as a duplicate of this bug. ***
I found another way to trigger constant repainting: going in and out of fullscreen mode with gwenview. 1. Have the 'Show paint' effect toggled on. 2. Open a picture with gwenview. 3. If gwenwiew started in fullscreen, the repainting has already started. 4. Otherwise, get it in fullscreen mode and see the repainting start. 5. Bring up the panel and see the repainting stop. 6. Switch out of fullscreen and the repainting starts again. 7. Bring up the panel and see the repainting stops. I tested some other apps that can go fullscreen: okular, firefox and eog do not trigger constant repainting. Gwenview has a relation to the panel via the 'Media Player' in the Systray, but so has firefox...
And another trigger is locking and unlocking the screen. The repainting starts after unlocking. I checked that by observing CPU via an SSH login. The repainting is stopped by making the panel visible. Letting the display sleep with "sleep 1; xset dpms force off" and waking it up again does not trigger repainting.
Hmm. Can't reproduce comments 24 and 25 any more after updating to Plasma 6.1.1 and rebooting. Could it have been the result of having 6.1.1 installed, but still running a session of plasma 6.1.0? Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Graphics Platform: X11
I wonder if we could log all the repaint requests in Qt windows, and then trace it down to QWidget or QQuickItem updates? I can't complain about CPU or GPU usage on my full-AMD laptop, but I do acknowledge that "Show Seconds: Always" causes unnecessary repaints every second when a panel is hidden. Can we track the panel's visibility in widgets to defer the updates?
*** Bug 492711 has been marked as a duplicate of this bug. ***
*** Bug 491034 has been marked as a duplicate of this bug. ***
I am able to reproduce the original problem on git-master, Wayland Using the Screen Paint effect makes the screen refresh problem obvious 1. Have a panel on auto-hide 2. Have 'top' running in a konsole 3. Switch to another virtual desktop - notice the screen paint effect start to flicker very rapidly. 4. Switch back to the original virtual desktop - the paint effect still flickers Also observe higher CPU use in kwin_x11, plasmashell and Xorg 5. Wait as long as you like. 6. Briefly make the panel visible 7. Observe the CPU use drop and the screen repaints stop I also noticed the entire screen being repainted with the animation from the CatWalk widget in the panel, or when the mouse moved over various pars of the Konsole window