https://bugs.kde.org/show_bug.cgi?id=356479
Lindsay Roberts <lind...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lind...@gmail.com --- Comment #87 from Lindsay Roberts <lind...@gmail.com> --- Confirmed Fabian's cause locally using perf/timers. It seems even worse than thought - in addition to legion allocations, it also iterates through the filesystem during KIconTheme construction, disk waits and IO on top of the visible CPU usage. A trivial test program did also turn up one more interesting bit about the problem; every time any icon in the systray changes - including a native KStatusNotifier based icon - all icons are refreshed, and this includes calling resolveIcon, and heap allocating KIconLoader/KIconTheme and it's associated fileystem iteration. Not only that, but the system tray QML references the icon (and resolveIcon) twice, so all this happens twice per affected icon, every time any icon changes. To salt that quite open wound, this includes icons hidden inside the expansion area, and in no plausible scenario needing immediate repaint. It is clear that KIconLoader is far too heavy to be constructed as part of any interactive or continuous operation. Without having spent too long in the code, the right place for any kind of cached per-application/per-icon data would seem to be in the statusnotifieritem datasource. And it seems that class actually has code for tracking a custom KIconLoader, resolving icons, and even sending them. It's possible that the code in resolveIcon is redundant, and is being used only because the QML prefers using the icon name to the QIcon() passed along: source: plasmoid.nativeInterface.resolveIcon(IconName != "" ? IconName : Icon, IconThemePath) Prefixing a preference for the provided icon before delving into resolveIcon (Icon ? Icon : ...) got rid of all significant CPU usage on my machine aside from the QML scene graph and the graphics drivers. Would require someone more knowledgeable in this area and/or significant testing to confirm this wouldn't produce any negative behaviour, however. Even with the above, we seem to be doing too much repainting due to small changes here, I haven't delved in enough to attempt to discover where and why the repaints are occurring. -- You are receiving this mail because: You are watching all bug changes.