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.
