Bug 504382

## During normal desktop operations Kwin regressed to use 2x to 2.5x CPU ##


## Detailed Steps to Reproduce ##

Just do what everyone does on the desktop:

1. Get this video watch?v=ljbpDc_s0T8 (270 plus 140, merge it for convenience into mkv container) to play offline (it's encoded with appropriate avc1 profile compatible with all intel GPUs);
2. Open Dolphin, don't close; you may also open one or two tabs of Firefox/Librewolf and, of course, Konsole;
3. $ pacman -S smplayer mpv (if you don't already have the GUI);
4. Set mpv.conf to hwdec=vaapi and vo=gpu-next;
5. Set smplayer GUI to vaapi and gpu-next (ctrl+P, general >> video; performance >> hardware decoding, 4 threads; loop filter >> skip only on HD videos);
6. Play the video with just mpv, observe behaviour in $ top (not htop). FYI: mpv skips Kwin;
7. Play the video with GUI where Kwin is not skipped
8. Compare (using top, not htop) 6 against 7 (use relative number, i.e. divide before/after and see the percentage of the regression). On slower CPUs (majority of Intel i3s it's a disaster).*

Some tips: If you are on Arch and still have Pulse instead of clean Pipewire, then don't. FYI Pulse on Arch has been broken for a long, long time resulting in very high CPU usage. Never fixed. By default mpv uses pipewire. If you have both then as temporary solution add ao=pipewire to mpv.conf. Remove pulse later to have clean pipewire. This will help to cleanly reproduce this bug.

## Observed Results ##

Kwin behaves nastily and *more than doubles* CPU usage (from 2x to 2.5x) . It's a critical regression of complete showstopper severity, that renders KDE useless and makes users to abandon KDE altogether. This regression bug has been affecting KDE for at least two months now without anyone caring.


## Expected results ##

1. Make hundreds of thousands of desktops with the current KDE version, on rolling releases, usable ASAP. These are your friends reporting bugs, pushing KDE forward. Without them you have zero bugs reports. Promptly update their desktops with critical update speed (Arch, Endeavour, Manjaro, Artix, Fedora Nightly, Fedora Rawhide, OpenSuse Tumbleweed, Kubuntu current...) with this immediate remedy: delete kwin ASAP and go back to historical version, before the code change, before this huge regression, happened.
2. Delete the affecting code, that caused this regression, altogether. It's nasty. Rewrite the code.
3. Fire the person who was responsible for this regression. At least when you make the change to some critical component that will affect everyone you should use your desktop with KDE for *at least 15* minutes with your code activated and observe if there is any CPU spike (always use relative number, i.e.: divide the number = CPU-after/CPU-before) and also run for 15 minutes to see if there is any RAM leakage. Example: on https audio only streams (FLAC), ffmpeg had a nasty "CPU leakage"- at first glance everything was OK. Playing the stream and simple observing the CPU usage in top for 1 minute, revealed nothing, but over time CPU went up and down, then more up and little down, then more up and just a little down. Over the span of 15 minutes it ate 100% CPU (You should thank me for this bug being fixed long time ago).
4. All programmers at KDE e.v. should *start using KDE as their daily driver* immediately. Explanation: How otherwise you would explain 2.5x (!) increase of CPU usage in normal desktop operation without nobody noticing. Wouldn't you hear CPU fan going crazy immediately and your lap getting hot? The only logical explanation is this: you DON'T use KDE as your daily driver, just like most Linux youtubers don't (I've noticed all of them use Apple; all that talk and not a single bug report; they are not our friends).
5. If you are still using KDE while coding, stop using very powerful computers and start using computers with limited resources so your change (and change of everyone else in the whole KDE team) will be obvious: loud fan, hot laptops, stutter, freezes, slowdowns. Old core i3, remove one die, leave only 4 GB of RAM (yes it is possible to use 4GB of RAM and KDE will work fine, as long as you don't have stupid systemd services, like 'stop job is running' etc in your system. Delete hungry, unnecessary services..., better: use limi Gentoo with openRC or s6 or runit in Artix). Limited resources will force you to care and you will immediately see what you did wrong. I repeat: absolute numbers on high end CPU/GPU mean nothing.
5. Inform Debian maintainers of this critical showstopper bug, so it won't land in Debian 13 (aka Trixie) in June (FYI: wayland is not 100% ready, so this Kwin X11 disaster must be fixed and treated with utmost emergency).
6. Push the reverted code to all the rolling releases as soon as possible. Make thousands of users happy.
7. There is no shame in asking for help. You cannot possibly know everything. Ask publicly for help from talented people who are writing compositors for wayland to find a few minutes a week to help you with this regression. Make kwin x11 as great as configured picom (I still remember how talented a person who wrote picom was. Switching a few options in picom config for Intel GPus did wonder. Unfortunately as good as KDE is, Kwin was never of such quality, and now its even worse. It is a sole component that, literally, as of now, killed KDE. Sad.).

component:
kwin 6.3.5 (and earlier)


kinfo:
Operating System: Arch
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Graphics Platform: X11
Memory: 3.7 GiB of RAM
Graphics Processor: Intel HD
Person: passionate about KDE.

## Additional Info ##

At least when you're switching now to wayland, you shouldn't touch the code of kwin for x11. It was working. For a long time it doesn't now. *Revert the code to the date of when it was working and only then put it into maintenance mode*. Wayland/Kwin is not yet smooth and not yet production ready. Now kwin/x11, is not production ready either (this regression reverted KDE to the alpha state) :(.