I ran into this bug in 5.7.0 with my Python 3 RSS reader: As the reader fetches new feeds, it updates the unread item count in its window title. This worked without problems with older versions of KDE, but in 5.7.0 it causes the task bar to hang with very high CPU usage. Sometimes it will recover on its own, other times I have to "xkill" it. Reproducible: Always Steps to Reproduce: Run the Python 3 script below. It sets up a Tk app and updates the window title and icon name very quickly, which should trigger this problem. With longer time intervals between updates (say, "root.after(20"), I also see the plasmashell issue, but the task bar will not lock up for as long. #!/usr/bin/env python3 from tkinter import * import random def title(): root.title("aaaaaaaa %u" % random.randint(1,5)) root.iconname("bbbbbbb %u" % random.randint(1,5)) root.after(5, title) class TkApp: def __init__(s, parent): s.parent = parent root = Tk() app = TkApp(root) root.iconname("test") root.after(500, title) root.mainloop() Actual Results: The Plasma taskbar becomes unresponsive for 45 seconds or so. The clock in the taskbar stops. Task bar cannot be used to switch between apps. CPU usage of plasmashell is very high. Expected Results: Task bar behaves normally. This is on a dual core Pentium-class system. On a faster CPU, behavior might differ.
Created attachment 99985 [details] Python 3 test script
P.S. I forgot to mention you are supposed to CTRL-C out of the demo script in the terminal, otherwise it will run forever.
P.P.S. And when I wrote Pentium, I was talking about a modern Pentium of course (basically an i3 without multi-threading), not a 1990s Pentium. Just to be clear...
I can confirm. It seems like it reloads (or re-queries from the model and thus reloads) the window icon whenever the title changes causing it to go crazy. #10 0x00007ffff33c7b14 in QImageWriter::write(QImage const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #11 0x00007ffff33a1d56 in operator<<(QDataStream&, QImage const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #12 0x00007ffff33d31cc in operator<<(QDataStream&, QPixmap const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #13 0x00007ffff4f863c4 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5 #14 0x00007ffff4f876a0 in KIconLoader::loadIcon(QString const&, KIconLoader::Group, int, int, QStringList const&, QString*, bool) const () from /usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5 #15 0x00007ffff4f7da94 in KIconEngine::pixmap(QSize const&, QIcon::Mode, QIcon::State) () from /usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5 #16 0x00007ffff33e5e48 in QIcon::pixmap(QWindow*, QSize const&, QIcon::Mode, QIcon::State) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #17 0x00007ffff33e5f0e in QIcon::pixmap(QSize const&, QIcon::Mode, QIcon::State) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #18 0x00007fffe050699a in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so #19 0x00007fffe0503ee6 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so #20 0x00007ffff51c04a4 in KWindowSystem::icon(unsigned long long, int, int, bool, int) () from /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5 #21 0x00007ffff51c04d7 in KWindowSystem::icon(unsigned long long, int, int, bool) () from /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5 #22 0x00007fff362ecadc in TaskManager::XWindowTasksModel::Private::icon(unsigned long long) () from /usr/lib/x86_64-linux-gnu/libtaskmanager.so.6 #23 0x00007fff362ed373 in TaskManager::XWindowTasksModel::data(QModelIndex const&, int) const () from /usr/lib/x86_64-linux-gnu/libtaskmanager.so.6
Wait a second. You actually constantly change the icon name in your script. So that it announces icon changes is to be expected, I missed that. But still, we should either compress those events or do something else more sensible than freezing. :)
Yes, and as I wrote this unresponsiveness persists for quite a while after you quit the script. I could understand a little task bar lag while the script is running, but the recovery after that is far too slow.
It most likely queues all the events and then processes them one by one so it continues long after the script has already quit.
Maybe it could use a timestamp for these events and drop them if they are older than a few seconds. Or maybe there should be a maximum length for the queue.
I can confirm it as well, I am making a game with libgdx and I ran into this issue. Plasma freezes up temporarily and uses ~95% of one of my cpu cores until it's unfrozen. I am running KDE Plasma 5.8.4, KDE Frameworks 5.28.0 if that is of any help.
This is somewhat a known todo. The old libtaskmanager contained event compression code ignoring updates across time slices of 200ms, the new libtaskmanager currently doesn't yet. It's mentioned in the FIXMEs/TODOs of the lib.
Does someone want to test if https://phabricator.kde.org/D7481 has any impact?
Upon running the Python script - Panel and Desktop become unresponsive - Plasma displays CPU usage up to 100% in htop utitility - and for one time after killing the script - Plasma didn't stop to consume CPU - how can i test the https://phabricator.kde.org/D7481 patch? Plasma: 5.12.2 Apps: 17.12.2 Frameworks: 5.43.0 Qt: 5.10.1 Kernel: 4.14.20-2-MANJARO OS: Netrunner Rolling
Git commit ec1931f7b2980a3cd445c09def1bb4a9b5ad607f by David Edmundson. Committed on 29/03/2018 at 14:38. Pushed by davidedmundson into branch 'master'. Batch window changes events on XCB Summary: In a log from someone talking about high CPU we can see get multiple X events for the same window as multiple events, but directly next to each other. This causes the TaskManager to process changes multiple times instead of just once which is a waste. An example is just pressing "enter" in konsole, which will pointlessly update the title. This causes problems for expensive app lookup and also QML performs text layouts immediately so any text changes cause quite large CPU usage if done more than 60fps; especially a task text resizing could result in resizing the entire panel. Something not relevant in kwin that also monitors these rolls. This class sits between KWindowSystem and XWindowTasksModel transparently buffering the changes. Related: bug 378010 Reviewers: #plasma, hein, broulik Reviewed By: #plasma, hein, broulik Subscribers: ngraham, cfeck, broulik, hein, graesslin, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7481 M +1 -0 libtaskmanager/CMakeLists.txt M +0 -1 libtaskmanager/TODO.txt A +80 -0 libtaskmanager/xwindowsystemeventbatcher.cpp [License: BSD] A +51 -0 libtaskmanager/xwindowsystemeventbatcher.h [License: BSD] M +6 -5 libtaskmanager/xwindowtasksmodel.cpp https://commits.kde.org/plasma-workspace/ec1931f7b2980a3cd445c09def1bb4a9b5ad607f
*** Bug 393748 has been marked as a duplicate of this bug. ***
*** Bug 399088 has been marked as a duplicate of this bug. ***