STEPS TO REPRODUCE 1. Go to https://meet.jit.si 2. Open a conference room and start sharing your whole screen OBSERVED RESULT In journalctl kwin_wayland spams ``` kwin_screencast: Dropping a screencast frame because the compositor is slow ``` roughly 20 times per second. EXPECTED RESULT No screencast frames are dropped SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230317 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.2-1-default (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series Pipewire: 0.3.67-1.1 Wireplumber: 0.4.13-2.1
I had used the wayland native Firefox 110.0 to screen sharing.
Noticed the same log output when trying to record a game via OBS Pipewire capture. There was no noticeable performance impact during gameplay, GPU and CPU were about 50% utilized. But when inspecting the recording it was completely broken and missing like 90% of frames. System Info: Plasma: 5.27.5 Frameworks: 5.106.0 Qt: 5.15.9 Pipewire: 0.3.70 Kernel: 6.3.2 CPU: AMD Ryzen 5 7600X GPU: AMD Radeon RX 6950 XT (used for encoding)
Might also be worth noting that next to those messages there are also a lot of those lines `kwin_screencast: Dropping a screencast cursor update because the compositor is slow`
How many of the `Dropping a screencast frame because the compositor is slow` messages are you seeing? Since 5.27.5 I've been getting a huge amount of that getting spammed in the logs even with just OBS open with a desktop capture (not even actually recording, just showing the preview), and KWin also ends up using one CPU core/thread at 100% in my case. As for the `Dropping a screencast cursor update because the compositor is slow` messages I've been seeing those since before 5.27.5 if I move my mouse around while recording the screen.
(In reply to Prajna Sariputra from comment #4) > How many of the `Dropping a screencast frame because the compositor is slow` > messages are you seeing? It varies, but I've seen it log up to ~30 per minute
> per minute per second*
I also did a few experiments Switching the iGPU back on and using that for encoding has the same result, same goes for using software encoding. So I think it's very unlikely that the encoder is at fault.
Tried the same thing on GNOME, using software encoding this time, and the recording was equally stuttery and unusable. So might be an issue in pipewire itself.
I was seeing this message without casting or recording, simply having a wayland enabled chromium or firefox had it producing lots these lines per second Ended up patching kwin_screencast to stop logging it
THE PROBLEM: Recording the screen via OBS + Vaapi is pretty smooth even at 144fps here, but the main problem (flood from kwin_screencast) is even worse, because if I use my monitor at 144hz, kwin_wayland starts using 100% of a single core and keeps flooding for more than ~200 messages PER SECOND, by just launching OBS or sharing screen on any app. I also tried increasing rtkit priority of pipewire proccess on it's settings (pipewire.conf), but the problem still happens. POSSIBLE ROOT OF THE ISSUE: So I noticed a possible cause of this problem by looking at a patch from PortageStuff (URL at the bottom of this comment). First of all, m_pendingBuffer is being set to true very frequently for some reason (pipewire fault?), so for every single dropped frame, the if statement is executing the qCWarning comamnd, which can both stress a CPU core and cause all the flooding. SUGGESTED WORKAROUND/FIX: If possible, for every second doing the screencast, track how much frames has been dropped and compare it to the target FPS. If more than 60% of the frames are being dropped, then finally send the kwin_screencast warning, because in this specific case the screencast performance is significantly worse than it should! SOFTWARE/OS VERSIONS AND HARDWARE: Operating System: Arch Linux (Updated at 8 June, 2023) KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.6-zen1-1-zen (64-bit) Graphics Platform: Wayland Pipewire: 1:0.3.71-2 Wireplumber: 0.4.14-1 Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 31,3 GiB de RAM Graphics Processor: AMD Radeon RX 5500 XT PortageStuff's patch: https://github.com/FireBurn/PortageStuff/blob/53f540ce02d32c1e8e9f13f23e0fcd3b9205e96b/patches/kde-plasma/kwin/spam.patch#L9
(In reply to Paulo Marcos from comment #10) > and keeps flooding for more than ~200 messages PER SECOND, by just launching Also this makes me wonder about the "if (m_pendingBuffer)": Is this statement checking "m_pendingBuffer" as fast as the CPU can handle? If there's no sleep() or even something similar to prevent this, every dropped frame (m_pendingBuffer == true) will send a lot of "kwin_wayland[1197]: kwin_screencast: Dropping a screencast frame because the compositor is slow" to the journalctl and use 100% of a CPU core.
Just patching out the QCWarning line does not resolve the problem of KWin using 100% of a single core in my case, I have to either revert KWin to 5.27.4.1 or revert commit 226d8c0a3b464f8870c45bfe5079f042a3cd5d67 (screencast: Ensure we respect the negotiated framerate) on top of KWin 5.27.5 to get that issue to go away. Also, I have filed bug 469777 specifically for the issue of high KWin CPU usage and the extremely high amount of "kwin_screencast: Dropping a screencast frame because the compositor is slow" messages (well beyond the 20-30 per second noted in this bug report originally, like hundreds or even up to a thousand per second), since my specific issue happened on 5.27.5 while this bug report is for 5.27.3, so they seem like different issues to me. I also don't see any issues with the recording output, but then again I only ever record at 60fps at most.
(In reply to Prajna Sariputra from comment #12) > Just patching out the QCWarning line does not resolve the problem of KWin > using 100% of a single core in my case, I have to either revert KWin to > 5.27.4.1 or revert commit 226d8c0a3b464f8870c45bfe5079f042a3cd5d67 > (screencast: Ensure we respect the negotiated framerate) on top of KWin > 5.27.5 to get that issue to go away. I reverted kwin to 5.27.4.1 on my system and confirmed: this fixes the 100% usage of a single core. While this problem is not fixed yet, i'm about to create a pull request to remove the kwin_wayland flood on 5.27 (doing the same way it's already fixed on master for plasma 6)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4171
Please note that kwin taking 100% CPU here is not this bug, please open a separate one and we'll discuss how to debug it there.
Hey guys! I assume that this problem is not related to kwin only. I use Gan charger with watt meter and I mentioned that when I move coursor in firefox with a lot of links on a page (youtube for example, amazon) the total power consumption of my laptop starts to grow up significantly, up to 25 watts but the PPT parameter of the CPU keep staying in a normal range - 2-6 watts. This kind of behavior usually means that something is overloading a graphic card. The command: "echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level" fixed the issue, at least I don't have 5 thousand strings in the log. I would like to note that simple browsing in firefox is not the case which would load GPU on a 100%. My laptop is ThinkPad t14 AMD Gen1 with Vega 10 graphics.
For me, this happens when I maximize or move different windows on screen, and increases if I play a video on Firefox at the same time, and also when I switch from an app to another via Task Manager. My journald is completely spammed by an infinite repeated message saying "kwin_screencast: Dropping a screencast frame because the compositor is slow". Operating System: Manjaro Linux KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-1-MANJARO (64-bit) Graphics Platform: Wayland
Hey guys, small update: It could be a placebo effect but I think that disabling all "Popups" effects ("system settings" > "workspace behavior" > "Desktop Effects") did the trick, at least it's been 3 days since I don't have hundreds "slow" errors in the logs. Since this problem mostly appears on AMD hardware I tried to tune amdgpu driver and rebuild kwin with " -mtune=znver2" (I have Ryzen 4750U with Vega 7 graphics). Had no luck but the number of those "slow" string became significantly lower and now I'm sure that something is going wrong between kwin and amdgpu, maybe some delays on a bus or something.
Created attachment 161409 [details] kwin_screencast repetitively connect/disconnect to/from plasma_screencast I don't know if this can help with the investigation process, but while I was using qpwgraph, it seems that simply hovering and moving over Task Manager elements makes kwin_screencast component to repetitively connect/disconnect to/from plasma_screencast component. See attached video for more info.
I don't use any kind of screencasting, but I found a bunch of this message in my logs while looking into a pipewire horkage. A big thing that stands out to me is that it's getting logged way more often than once per frame: >> journalctl -o short-iso | uniq -c | sort -hk 1,1 | tail -n30 | sort -k 2,2 > 7060 2023-08-07T16:06:46-0500 redacted kwin_wayland[5031]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 7099 2023-08-07T16:06:47-0500 redacted kwin_wayland[5031]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 7306 2023-08-19T16:43:53-0500 redacted kwin_wayland[3749]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 19378 2023-08-25T13:06:20-0500 redacted kwin_wayland[3749]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 8665 2023-08-31T14:20:05-0500 redacted kwin_wayland[3228]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 7840 2023-09-01T18:31:16-0500 redacted kwin_wayland[3228]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 9367 2023-09-11T18:10:03-0500 redacted kwin_wayland[3558]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 11183 2023-09-11T18:10:04-0500 redacted kwin_wayland[3558]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 8967 2023-09-11T18:10:07-0500 redacted kwin_wayland[3558]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 10209 2023-09-17T15:47:08-0500 redacted kwin_wayland[382216]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 20907 2023-09-17T15:47:09-0500 redacted kwin_wayland[382216]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 9436 2023-09-20T11:02:07-0500 redacted kwin_wayland[382216]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 9205 2023-09-20T11:10:41-0500 redacted kwin_wayland[382216]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 21662 2023-09-20T11:10:42-0500 redacted kwin_wayland[382216]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 9653 2023-09-23T14:57:39-0500 redacted kwin_wayland[2905]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 11974 2023-09-25T21:38:10-0500 redacted kwin_wayland[2905]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 7066 2023-09-28T14:09:07-0500 redacted kwin_wayland[2905]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 26433 2023-09-28T14:09:08-0500 redacted kwin_wayland[2905]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 21379 2023-10-04T12:25:04-0500 redacted kwin_wayland[2811]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 23671 2023-10-05T02:41:04-0500 redacted kwin_wayland[849797]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 16671 2023-10-06T20:56:34-0500 redacted kwin_wayland[2782]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 7475 2023-10-18T21:03:48-0500 redacted kwin_wayland[6469]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 12455 2023-10-24T18:06:24-0500 redacted kwin_wayland[6469]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 37496 2023-10-26T09:02:45-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files > 8160 2023-10-26T09:02:55-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files > 25519 2023-10-26T09:02:56-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files > 10110 2023-10-26T09:03:25-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files > 27389 2023-10-26T09:03:26-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files > 9629 2023-10-26T09:03:55-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files > 27870 2023-10-26T09:03:56-0500 redacted pipewire[6468]: mod.protocol-native: server 0x55f7387c2b40: failed to accept: Too many open files Looking at the incident on 2023-10-24, the log around that time has: > 127 2023-10-24T18:06:23-0500 redacted kwin_wayland[6469]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 12455 2023-10-24T18:06:24-0500 redacted kwin_wayland[6469]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 1514 2023-10-24T18:06:25-0500 redacted kwin_wayland[6469]: kwin_screencast: Dropping a screencast frame because the compositor is slow > 1 2023-10-24T18:06:25-0500 redacted wireplumber[6471]: <WpSiStandardLink:0x5643cb4ddd70> 1 of 1 PipeWire links failed to activate > 1 2023-10-24T18:06:31-0500 redacted kwin_wayland[6469]: This plugin does not support raise() > 1 2023-10-24T18:08:07-0500 redacted kate[2439564]: qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x55766f2d4be0> > 2 2023-10-24T18:08:14-0500 redacted kate[2439564]: qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x55766f2d4be0> > 1 2023-10-24T18:08:17-0500 redacted kate[2439564]: qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x55766f2d4be0> > 1 2023-10-24T18:08:45-0500 redacted pipewire[6468]: mod.client-node: 0x55f738e29530: unknown peer 0x55f738b221e0 fd:957 > 1 2023-10-24T18:08:46-0500 redacted pipewire[6468]: mod.client-node: 0x55f738d2a810: unknown peer 0x55f738a95240 fd:953 > 1 2023-10-24T18:08:55-0500 redacted kwin_wayland[6469]: This plugin does not support raise() > 1 2023-10-24T18:09:02-0500 redacted kwin_wayland[6469]: This plugin does not support raise() > 1 2023-10-24T18:09:37-0500 redacted kwin_wayland[6469]: This plugin does not support raise() > 1 2023-10-24T18:09:42-0500 redacted kwin_wayland[6469]: This plugin does not support raise() > 1 2023-10-24T18:09:53-0500 redacted kwin_wayland[6469]: This plugin does not support raise() > 1 2023-10-24T18:10:01-0500 redacted kwin_wayland[6469]: This plugin does not support raise() Using this pipeline (fish syntax): > journalctl -o short-iso | grep 'screencast frame because the compositor is slow' | uniq -c | python -c 'import sys'\n'for line in sys.stdin:'\n' if (int(line.split()[0]) > 1000):'\n' print(line.strip())' The oldest recorded incident of more than 1000 messages in one second was on 2023-07-28, but that's as far back as the log goes, presumably because the spam has forced rotation of everything before that.
Oops, missed a line in my copy pasting and Bugzilla does not allow edits apparently. That 10-24 incident should be preceded by >2023-10-24T18:06:23-0500 redacted pipewire[6468]: mod.client-node: 0x55f738b40710: unknown peer 0x55f738a95240 fd:934
Same here on Arch Linux, KDE 5.27.9, Frameworks: 5.112, QT : 5.5.11. Wayland session. Intel iGPU. Only Obsidian is running, and journald is flooded with more than 90.000 line of `kwin_screencast: Dropping a screencast frame because the compositor is slow`. I have no screencasting.
> journalctl -o short-iso | grep 'screencast frame because the compositor is slow' | uniq -c | python -c 'import sys'\n'for line in sys.stdin:'\n' if (int(line.split()[0]) > 1000):'\n' print(line.strip())' Python part didn't want to work for me, so replaced with awk: journalctl -o short-iso | grep 'screencast frame because the compositor is slow' | uniq -c | awk '{ if ($1 > 1000) print($0) }' I knew the spam was excessive, but my "high score" of 24908 is quite unexpected, although the 5 digit counts are not that common. Ironically currently I was checking the log to see if there's anything there related to Firefox video stuttering, but then as medin mentioned, the spamming often goes hand in hand with activities related to video playback in Firefox. Opened up qpwgraph, can't reproduce rapid reconnecting for previews, but I do remember the previews flickering in the past which was likely the mentioned anomaly, and often they don't really work right, but then I very rarely try to hover for previews intentionally, so not keeping track of it much. Bit unrelated, but it's really amusing to see all open AliExpress tabs in qpwgraph. Yay for shitty fingerprinting with annoying side effects.
This warning has been dropped and that warning can be ignored.