Bug 356479

This is actually not specific to octopi-notifier. I just had a connection issue and the network applet kept trying to connect, which also displayed the "connection" animation in the task bar, and I had exactly the same issue. My computer was very laggy (the mouse would "jump" on the screen) and plasmashell CPU usage was increasing.

Stopping the connection would fix the issue (plasmashell CPU usage would go back to 0%) and trying to connect again would bring the issue back again.
For octopi, when there is an update, it changes the icon in the task bar and it's animated as well.

I added two issues which seem related. Maybe https://bugs.kde.org/show_bug.cgi?id=351923 is also related?

Sorry, I totally missed your IRC query :)
What Plasma Frameworks version are you running? There's a bugreport about this ("spinner causes 100% cpu") but I can't find it right now.

No problem :) Thanks for the reply

I am on ArchLinux, I had 5.5.2, and I just upgraded to 5.5.3 a few minutes ago.

I'm guessing you might mean this:
https://bugs.kde.org/show_bug.cgi?id=353974

Does seem we have a problem that only exhibits on some systems but not others.
I just got a callgrind log from a colleague when quassel was animating in the system tray using 80%. On my system with the exact same trigger ~1%, everything fine.

What was interesting in the trace is we got a huuuuge amount of X events. ~50000 in around 10 seconds. This accounts for 25% of the CPU usage. Identity that and we'll probably fix most the problem.

Git commit 3936e2230d71948d4bd70c062f34d6cbc93e69c3 by David Edmundson.
Committed on 20/01/2016 at 08:56.
Pushed by davidedmundson into branch 'master'.

Cache QX11Info::appRootWindow in eventFilter

appRootWindow is (relatively) expensive and won't change.
nativeEventFilter is called a lot

This should speed things up.
REVIEW: 126818

M  +6    -5    src/platforms/xcb/kwindowsystem.cpp
M  +2    -0    src/platforms/xcb/kwindowsystem_p_x11.h

http://commits.kde.org/kwindowsystem/3936e2230d71948d4bd70c062f34d6cbc93e69c3

Note whilst I can still remember. 

xcb_generic_event_t.response_type == 
102
103

This doesn't seem to fix the issue. I mean, when there is any animation, it seems to use at least 15% CPU constantly. I don't currently have time to wait longer to see if it increase to 100% over time like it did before. Will keep octopi notifier enabled and report back.

This seem better than before, but I still can't use anything that have animations, since the constant CPU usage of 15% of the plasmashell process makes my laptop fan consistently spin up and spin down, this makes too much noise.

I had the same thing:

My connection got lost, and plasmashell used >100%CPU until I disable/enable the connection.

*** Bug 357597 has been marked as a duplicate of this bug. ***

Is there any info I can provide to help fix the issue, or is the cause already known?
This is very annoying and cause my mouse to be very laggy every time it happens. 
It just needs any program to have an icon with an animation...

When porting the weather applet I found that every time the one used PlasmaComponents.BusyIndicator is visible, it keeps 2 cores complete busy here (e.g. when testing the applet with plasmawindowed).
(Plasma 5.5.4 OpenSuse Tumbleweed).

Caching QX11Info::appRootWindow obviously helps (btw, starting in what version of KDE it's available?) but this is not the solution.
Do we know the real cause?
It looks like animations should be rate limited and do not take CPU time to calculate frames which are going to be never displayed. If so it looks very similar to problem with touch events which is described here https://blog.rburchell.com/2014/09/profiling-is-not-understanding.html :
"This was, in turn, causing QtQuick to run touch processing (involving costly item traversals, as well as the actual processing of touch handling) a lot more frequently than the display was updating."
I'm wondering why this hasn't been fixed for so long taking into consideration that this bug seriously impacts such widely used project like KDE...

I'm tired of this bug, and other similar ones (I'm getting high CPU usage on plasmashell even without any animation quite often) and now switched to Gnome, which isn't impacted by such bugs. 
I have animations with the system tray icons (e.g. kalu) in Gnome as well, but the CPU usage doesn't change and everything stay smooth. So there is definitely something that KDE/Qt doesn't do properly.

This is related to bug #336274, which reports 100% CPU usage in the specific case where a network connection is stuck in a "Connecting" or "Preparing to connect" status (with the corresponding taskbar animation).

Persists in Plasma 5.6.2 with framework 5.18.0 (Gentoo).

Possibly related: https://bugs.kde.org/show_bug.cgi?id=347237 (and not only nvidia, also an intel problem, like for me).
"export QSG_RENDER_LOOP=basic" has been reported there and elsewhere to work-around the issue for now.
So perhaps this bug can be solved as duplicate then? Sadly the other bug is resolved as "upstream", and https://bugreports.qt.io/browse/QTBUG-45959 is still "Open" :(

I can confirm the bug on Manjaro Plasma 5.6.3 with KFramework 5.21. When I close the octopi-notifier, the plasmashell CPU usage goes away. Until than it is 2-4% and it is increasing.

I can confirm on ArchLinux, plasmashell version 5.6.3. Plasmashell proces grows in CPU usage when there is anything "animated" in the system tray - for instance a Connecting state (I have a problem when ethernet is constantly trying to connect even with the cable out so the icon is still moving - after minutes, the enviroment becomes unusable), skype connection (spinning the arrows), or notification.

I have also observed using htop, that the loads usually starts at 10 - 15 % on all cores per moving icon and grows up to 80 - 100% per core, at which point the desktop is not usable any more.

Adding export QSG_RENDERLOOP does not help here, CPU usage is still ~20 % for plasmashell, 15% for kuiserver 10 % for dolphin and 10 % for file.so copying a simple file. This is disappointing.

Same issue here on archlinux and plasma 5.6.3, konversation blinking icon makes the CPU raised close to 80%.

Another thing : removing the panel and creating a new one has the same effect + 5GB of memory consumed within a few seconds...

Still have 60 % with plasma 5.6.4...

Confirming. konversation blinking icon eats a lot of CPU time.

Same problem arch, plasma 5.6.4.
Fixible by using xf86-video-intel with mesa-libgl.

What do you mean with "fixable by using xf86-video-intel and mesa-libgl"? I am running Intel HD4400 graphics and still the problem occurs.

Same question here, I have the 2 packages you told us but I still have the problem (and a lot more)...

The situation is now worse:

If when I'm away/asleep a notification is triggered, the CPU runs the whole time. When I see it, I stop the notification, but plasma doesn't recover well: it stays very slow and freezes. I need to kill it, it hangs for 10-30s and then disappear. After starting plasmashell again, everything is back to normal.

Note: When I'm away, my session is locked and the lid closed (but not suspended): the problem occurs anyway..

Does running:

QSG_DISTANCEFIELD_ANTIALIASING=subpixel-lowq plasmashell

make a difference?

I ran plasmashell as you proposed. It didn't go to 100% at once but progressively:

The CPU consumption of plasma mounted to 10% stayed around this value, then to 12%, stayed  a little and so on, until I kill it around 35%. (in less than 2 minutes)

Since last qt5-base update (5.6.0-6 on archlinux) it seems to be corrected.

Could you confirm?

Could somebody please tell us what the bug we should follow is so that we could stop guessing weather this was fixed or not with every minor release of qt/kde?

Hi Piotr,

I could easily reproduce it with konversation, ask someone to ping you on IRC and you will see your cpu starts acting crazy around 60 to 80 % when the icon blinks.

Hi guys,

I tested this morning with qt5-base 5.6.0-6 and I still have plasmashell using from  30 to 80 % between each blink :(

Same thing with 5.6.0-7 :(

Will this solve the problem?
https://blogs.kde.org/2016/05/31/new-plasma-task-manager-backend-faster-better-wayland

Maybe but we have to wait for 5.7 release scheduled for mid july to test this :(

Do someone know how to disable icon animation / blinking ?

Noticed this many times on opensuse (presently leap 42.1, but also earlier), sometimes it comes sometimes it goes.

But I found a workaround by deleting the panel (noting there were actually several behind each other, I removed them all) and then creating a fresh one. This one still shows, although the connection is stable, the circling "connecting to..." symbol, but what is important, the CPU load and fan activity is gone.

(In reply to wcramer from comment #38)
> 
> But I found a workaround by deleting the panel (noting there were actually
> several behind each other, I removed them all) and then creating a fresh

For this specific problem see bug 356225 and bug 358011.

(In reply to Piotr Dobrogost from comment #39)
> (In reply to wcramer from comment #38)
> > 
> > But I found a workaround by deleting the panel (noting there were actually
> > several behind each other, I removed them all) and then creating a fresh
> 
> For this specific problem see bug 356225 and bug 358011.

yes, thanks, but I find this all hugely complicated (I am using several dual screen set ups at home and at work), so I don't mind just killing the panels and create a new one. My point was, however, this seems to truly fix the problem described in this thread here, and maybe therefore provides a hint at what is causing the CPU load?

The issue still exists after recreating the panel.

At the end, the problem is not triggered by Konversation anymore, but skype and network manager still make the bug occur. So not solved now

How many reports does this need before this get fixed, or at least before someone tell us what kind of information is needed to fix this?

This bug is driving up my CPU temperature to 95°...

This issue doesn't happen with the wayland session, the CPU usage of plasmashell is always 0%. Unfortunately, the wayland session is not usable right now.

Same issue on Plasma 5.6.5.1 with KF 5.22.0. 
i3 CPU, 70-80 % usage, 80 C warm....

Same here on a laptop with i5 CPU, intel graphics, KDE 5.7.1 on Arch Linux.

Confirming. konversation blinking icon eats a lot of CPU time.
When konversation stops blinking, the CPU usages is reduced immediately.

X.org 1.17.4, Plasma 5.7, KF 16.04.2

To be more precise, the CPU usages is caused by the animated konversation icon in the system tray.
A highlighted konversation in the taskbar does not affect CPU usage.
When konversation starts blinking CPU usage goes to 30% and stays there. CPU usage immediately disappears when konversation stops blinking.

this bug (or its many variants) has been ongoing since 2012 (im currently on plasma 5.7.0). It is a big problem for the use of laptops on battery. I cannot understand a design descision which prioritises  "graphical fluff" over system functionality and the sanity and time of your users. 

The modification of .../NotificationIcon.qml only appears to work for notifications regarding file coying etc and not network connections, which as i found out today can go on for a very long time in a workspace with tempromental  wifi. 

If, (as it would seem) it cannot be fixed, could we have either a formal (control option) or informal (edit files etc) to silence the problem?

One of the advantages of QML is to show animations efficiently with low CPU usage.
So something very strange must be going on here.
I'm not familiar with profiling QML applications, but could try it if someone points me to description of how to do it. I'd prefer to connect the profiler to the running plasmashell. I've no debug symbols installed for Plasma.

I noticed this commit in the Plasma 5.7.2 which may alleviate the problem a bit:

https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=1caec23e0e9201e7353e15267f9ea28d9c3653f1

Created attachment 100349 [details]
Patch to confirm cause

The issue is that for every SNI notification with iconThemePath set, it (heap) allocates a lot of stuff, including an KIconLoader and KIconEngine.
(SystemTray::resolveIcon in plasma-workspace/applets/systemtray/systemtray.cpp)
I quickly hacked a patch together to confirm that this is actually the cause for the load. It seems to improve the cpu % significantly with skype.
The result is that most of the time is spent in malloc. I found that with perf record --call-graph plasmashell easily.
sni-qt uses IconThemePath by default, but neither KStatusNotifierItem nor QSystemTrayIcon do, so I guess that only Qt4 apps are affected.

Can someone confirm that the patch also works for other "plasma-breaking" programs?

@devs:
Is the correct approach for a fix to cache the final QIcon? If yes, I'd like to make a proper patch and put it up for review.
I'd like to reduce the amount of allocations in that context (like KIconLoader in AppIconLoader), but I don't see an easy way to fix that.

proliferation: 

To note i can also  get 2 bugs regarding the spinner cpu problem by adding an extra "task manager" on the desktop. The first is as usual, 1 full core used by spinner. In addition i get random spinners that never stop. This often occurs opening pdfs with okular, sometimes with Ksysguard, sometimes by having more than 1 instance of a program eg Dolphin. The spinner continues indefinitely regardless of application state.  Further observations: 
* the cpu usage continues even if the spinner graphic is covered by another application window. 
* if the offending app is closed the spinner can jump to another app in the view.
* turning off "show status on icon" control option makes no difference.
If you can reproduce this behaviour perhaps this could also provide a reliable source for profiling/debugging.

(for info i changed the lower panel to icon only, then placed the full task manager on the desktop)

Created attachment 100377 [details]
Spinner rotating and eating CPU despite network being connected

This spinner is eating about 140% of CPU according to top. Not very good for battery life ...

plasma 5.7.0 / openSUSE Tumbleweed

To fix, I just do "pkill plasmashell", works like a charm every time.

As others have observed, copying files in Dolphin, particularly across the network, results in this plasmashell CPU overload.

But it turns out that, for me, the most frequent source of this problem is the tray icon of Amarok (the audio player). A few days ago, I disabled Amarok's (very useful but oh well) tray icon in Settings > Configure Amarok > General. Since then, plasmashell's CPU overload problem has not recurred.

Created attachment 100383 [details]
attachment-24892-0.html

I don't thing think the solution to this I tweaking this or that or hoping
that every time there is an update or the wind changes direction it might
be fixed. There is something fundamentally wrong which I assume should not
be that difficult to find via profiling. I did some comparisons of CPU
usage for things like scrolling a PDF and CPU usage was an order of
magnitude less than any of the many instances of status/spinner
requirements.

On 30 Jul 2016 3:21 a.m., "Trevor Parsons via KDE Bugzilla" <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #56 from Trevor Parsons <kdebugs@trevorparsons.com> ---
> As others have observed, copying files in Dolphin, particularly across the
> network, results in this plasmashell CPU overload.
>
> But it turns out that, for me, the most frequent source of this problem is
> the
> tray icon of Amarok (the audio player). A few days ago, I disabled Amarok's
> (very useful but oh well) tray icon in Settings > Configure Amarok >
> General.
> Since then, plasmashell's CPU overload problem has not recurred.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

Created attachment 100406 [details]
Perf report while plasmashell running at 100%

Here is perf which I ran against plasmashell.

Created attachment 100407 [details]
strace of plasmashell

Here is an strace.

Created attachment 100408 [details]
attachment-28198-0.html

not sure what to make of all this, im a dumb python programmer! do you
actually have high cpu with spinners going?

On 1 August 2016 at 15:10, Samantha McVey via KDE Bugzilla <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #59 from Samantha McVey <samantham@posteo.net> ---
> Created attachment 100407 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=100407&action=edit
> strace of plasmashell
>
> Here is an strace.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to nicholas from comment #60)
At that time I didn't see any movement in the tray, but that usually seems to be what triggers the bug, or at the very least makes it occur quicker and worse.  I am using 5.7.2 btw.

*** Bug 364518 has been marked as a duplicate of this bug. ***

*** Bug 365215 has been marked as a duplicate of this bug. ***

My issue seems to be related to any app that places an icon in the system tray. As I remove/close apps, plasmashell usage drops a little for each additional closed app. Hogs include Chrome, Skype and others. Right now, my process % is around 25% ( ~80% of 1 core on 6-core machine ) but has gone as high as 70%. My issue does not just happen with animated icons ...

This issue started with Plasma 5.6 and continues to 5.7.2 as of now.

*** Bug 363909 has been marked as a duplicate of this bug. ***

*** Bug 364061 has been marked as a duplicate of this bug. ***

I dont' think it necessarily have anything to do with animated icons in the tray.

While I was working on the new Picture frame plasmoid I've seen the exact same symptoms when using long running QML animations (I used one for showing a count down in the widget which animated all the time) - so I had to remove it. I think it's related to Plasma in some layer just above Qt (maybe Plasma controls screen update timing?) - I have a multi monitor setup BTW

What is the modification to NotificationIcon.qml mentioned by Nicholas? I've the same problem especially for copying file over the network,

Searching I've found a workaround to disable the spinning in BusyIndicator. Works for me, but disables the animation.

https://bugs.kde.org/show_bug.cgi?id=312920#c3

Glad you found the patch.

Just thinking of alternate approach to identify the source of this:
1. someone who knows QT writes a small app containing spinner.
2. spinner can now be triggered in a controlled manner, we can test the effect of controlling parameters. 
3. uses on different systems can compare behaviour in a quantitative manner
4. push this back up through KDE/QT to find the source of the issue.
At a guess i assume it is something relatively simple like excessive/duplicate screen updates

*** Bug 351448 has been marked as a duplicate of this bug. ***

Is it there any progress on this? Plasma 5.8 is LTS and still has this bug, that seems quite critical to  me. There are multiple animated icons in the task bar and some of them keep the animation running for a long time causing the CPU to be always on.


- File transfer
- Skype
- Update notification on Manjaro (I need to kill this or update the system, or my CPU is always on).

I've basically removed every widget from the desktop that would (even if not visible) drive up my CPU like crazy - especially to save battery time.

(In reply to Simone Gaiarin from comment #72)
> Is it there any progress on this? Plasma 5.8 is LTS and still has this bug,
> that seems quite critical to  me. There are multiple animated icons in the
> task bar and some of them keep the animation running for a long time causing
> the CPU to be always on.
> 
> 
> - File transfer
> - Skype
> - Update notification on Manjaro (I need to kill this or update the system,
> or my CPU is always on).

As far as I can tell there are actually two separate bugs: The one is for system tray icons (such as skype or your update notification) and my patch fixes that and the other one is with animated task manager (?) icons, such as file transfer.

(In reply to Fabian Vogt from comment #74)
> (In reply to Simone Gaiarin from comment #72)
> > Is it there any progress on this? Plasma 5.8 is LTS and still has this bug,
> > that seems quite critical to  me. There are multiple animated icons in the
> > task bar and some of them keep the animation running for a long time causing
> > the CPU to be always on.
> > 
> > 
> > - File transfer
> > - Skype
> > - Update notification on Manjaro (I need to kill this or update the system,
> > or my CPU is always on).
> 
> As far as I can tell there are actually two separate bugs: The one is for
> system tray icons (such as skype or your update notification) and my patch
> fixes that and the other one is with animated task manager (?) icons, such
> as file transfer.

1. your patch does not seem to have progressed since proposal?, or could you update on status?

2. instead of trying to fix this why not bypass the issue, use a static graphic e.g. a "cloud" around the icon instead of animated spinners? using half my system resources to indicate a file is transferring is an extremely poor trade-off.

(In reply to Fabian Vogt from comment #74)
> (In reply to Simone Gaiarin from comment #72)
> > Is it there any progress on this? Plasma 5.8 is LTS and still has this bug,
> > that seems quite critical to  me. There are multiple animated icons in the
> > task bar and some of them keep the animation running for a long time causing
> > the CPU to be always on.
> > 
> > 
> > - File transfer
> > - Skype
> > - Update notification on Manjaro (I need to kill this or update the system,
> > or my CPU is always on).
> 
> As far as I can tell there are actually two separate bugs: The one is for
> system tray icons (such as skype or your update notification) and my patch
> fixes that and the other one is with animated task manager (?) icons, such
> as file transfer.

1. your patch does not seem to have progressed since proposal?, or could you update on status?

2. instead of trying to fix this why not bypass the issue, use a static graphic e.g. a "cloud" around the icon instead of animated spinners? using half my system resources to indicate a file is transferring is an extremely poor trade-off.

(In reply to nicholas from comment #76)
> (In reply to Fabian Vogt from comment #74)
> > As far as I can tell there are actually two separate bugs: The one is for
> > system tray icons (such as skype or your update notification) and my patch
> > fixes that and the other one is with animated task manager (?) icons, such
> > as file transfer.
> 
> 1. your patch does not seem to have progressed since proposal?, or could you
> update on status?

It's mainly a PoC and workaround and not a proper fix. It still applies to current plasma-workspace git.

My workaround for the spinning file transfer is to modify the qml code and make it not spin. What other  "animated task manager (?) icons"  are causing the problem beside the file transfer spinner?

I still haven't tried your patch for the system tray icon. Can I just recompile the system tray or does it require to recompile the whole plasma?

The weird thing is that this issue does not happen with Plasma Wayland, so it is probably not only related to only "malloc", but this might be an issue in the X11 specific code.

Created attachment 101374 [details]
attachment-8670-0.html

Modifying the qml gets tedious due to updates, especially tumbleweed

On 2 Oct 2016 11:49, "Simone Gaiarin via KDE Bugzilla" <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #78 from Simone Gaiarin <simgunz@gmail.com> ---
> My workaround for the spinning file transfer is to modify the qml code and
> make
> it not spin. What other  "animated task manager (?) icons"  are causing the
> problem beside the file transfer spinner?
>
> I still haven't tried your patch for the system tray icon. Can I just
> recompile
> the system tray or does it require to recompile the whole plasma?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to Simone Gaiarin from comment #78)
> My workaround for the spinning file transfer is to modify the qml code and
> make it not spin. What other  "animated task manager (?) icons"  are causing
> the problem beside the file transfer spinner?

I don't know, I haven't hit that bug, only the tray icon one with skype.

> I still haven't tried your patch for the system tray icon. Can I just
> recompile the system tray or does it require to recompile the whole plasma?

You only need to rebuild %{_libdir}/qt5/plugins/plasma/applets/org.kde.plasma.private.systemtray.so

Created attachment 101376 [details]
attachment-15218-0.html

On my system it seem to be whenever theres "movement" on the screen;
animated icons, youtube playback in chrome makes CPUs sweat, animated fades
between two images in the Picture frame plasmoid, drawing in Krita etc. the
CPU is up 20 - 40%. I've developed a game in Qt which uses a lot of QML
animations but it doesn't do anything to the CPU so it must be a plasma
thing of some sort :/

On 11:57, Sun, 2 Oct 2016 Fabian Vogt via KDE Bugzilla, <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #81 from Fabian Vogt <fabian@ritter-vogt.de> ---
> (In reply to Simone Gaiarin from comment #78)
> > My workaround for the spinning file transfer is to modify the qml code
> and
> > make it not spin. What other  "animated task manager (?) icons"  are
> causing
> > the problem beside the file transfer spinner?
>
> I don't know, I haven't hit that bug, only the tray icon one with skype.
>
> > I still haven't tried your patch for the system tray icon. Can I just
> > recompile the system tray or does it require to recompile the whole
> plasma?
>
> You only need to rebuild
> %{_libdir}/qt5/plugins/plasma/applets/org.kde.plasma.private.systemtray.so
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

The video lag on chrome may be related to other causes. I had the problem as well. 
See this: https://forum.manjaro.org/t/chrome-chromium-and-html5-video-lags-low-fps/2257/30

Created attachment 101378 [details]
attachment-19338-0.html

Well video plays fine - at good framerates -  but the CPU cores are working
absurdly - which makes it feels like plasma is part of it. I'll have a look
at top the next time

On 15:22, Sun, 2 Oct 2016 Simone Gaiarin via KDE Bugzilla, <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #83 from Simone Gaiarin <simgunz@gmail.com> ---
> The video lag on chrome may be related to other causes. I had the problem
> as
> well.
> See this:
>
> https://forum.manjaro.org/t/chrome-chromium-and-html5-video-lags-low-fps/2257/30
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

Before it was only animated icons that were causing high cpu usage but now it seems it's anything ... I'm watching a movie with mpv and then after half an hour I see jitter and then `ps aux` confirms it's plasmashell.  CPU usage is on average 28% here but it jumps to 130% about every two seconds according to `top`. And now I have confirmed it .. this cpu usage happens if either Skype or Spotify are enabled so it leads me to believe it must be this SNI or XEmbed integration that's somehow broken.

Popping by again just to say that I haven't got Skype or Spotify on my system

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.

@Lindsay Roberts: in which file did you apply this change? I'm hoping this can be applied in-place in the filesystem if it's only a QML file.

The file is /usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/items/StatusNotifierItem.qml locally. If you try this, let us know if you see the same icons before and after or any other changes. Can't guarantee this doesn't produce some kind of huge regression.

These are the changes I made:

Line 31:
    //icon: ToolTipIcon != "" ? ToolTipIcon : plasmoid.nativeInterface.resolveIcon(IconName != "" ? IconName : Icon, IconThemePath)
    icon: ToolTipIcon != "" ? ToolTipIcon : Icon ? Icon : plasmoid.nativeInterface.resolveIcon(IconName, IconThemePath)

Line 51:
        //source: plasmoid.nativeInterface.resolveIcon(IconName != "" ? IconName : Icon, IconThemePath)
        source: Icon ? Icon : plasmoid.nativeInterface.resolveIcon(IconName, IconThemePath)

We have about 3 different bugs all merged into one here, which is partly why we haven't moved this much.

We have:
1) The heavy kiconloader usage when using an SNI which is updating constantly 

2) We have the extreme number of pointless X messages causing us to spend lots of CPU time in nativeEventFilter (and thus strcmp)

3) Any other GL related delays stuff, such as (hopefully now gone) NVidia busy loop waiting for vsync.


Lets keep this bug as (1) and can close with https://phabricator.kde.org/D2986

I will reopen as 370003 issue for (2) and track that there.

For that reason, when this is merged if you still have high CPU, please don't reopen this as it's probably a different cause.

For all those playing at home, the change in https://phabricator.kde.org/D2986 has now been committed. This makes the changes I suggested above as well as completely removing the code identified in the perf traces.

Anyone willing to test master to help confirm the fix and it's lack of side effects is extremely welcome.

Am marking this bug resolved - it's scope being as David mentioned above, systray related CPU usage.

High CPU usage when copying files via Dolphin with task status is still a problem; suggest we track that in the existing specific item https://bugs.kde.org/show_bug.cgi?id=312919 . Doesn't seem to be the same as issue (2) mentioned above, perf shows lots of dbus.

Did the patchset make it to 5.8.2? I am currently suffering from this bug while using the aforementioned version. Backing up my phone and the notification wheel is spinning. Plasma feels choppy and using 29% of my i5-4670 constantly.

On a side note, pausing the transfer does not stop the animation (it should).

> Did the patchset make it to 5.8.2? 

No, only master branch (which will become 5.9) so far.

But maybe it could be also added to 5.8.3, since it is a bugfix and also does not involve any major changes? Thus users would get it in November already.

*** Bug 371844 has been marked as a duplicate of this bug. ***

*** Bug 371853 has been marked as a duplicate of this bug. ***

*** Bug 336274 has been marked as a duplicate of this bug. ***

on my system

> KDE Frameworks 5.28.0
> Qt 5.7.0 (kompiliert gegen 5.7.0)
> Das xcb Fenstersystem

the problem ist still present. And I can only get rid of the load by killing plasmashell and starting it again if i need it... :(

For me it's fixed since Plasma 5.8.

Created attachment 102521 [details]
attachment-26268-0.html

After a superficial test, copying files over the network (that was usually
killing the CPU) the problem seems not be present in Plasma 5.8.4. But
since the problem kicks in randomly this test is not enough to say it's
solved.

On Tue, Nov 29, 2016 at 4:44 PM Jos van den Oever <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #101 from Jos van den Oever <jos@vandenoever.info> ---
> For me it's fixed since Plasma 5.8.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Plasmashell process eats 26% cpu which must be one thread on my Thinkpad.
All I'm doing is connecting to wifi.

i5-3320m
HD4000
Xorg modesetting driver
Plasma 5.8.4
Arch
If it's somehow relevant:
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)

https://paste.kde.org/p2ikerwvu

(In reply to Lindsay Roberts from comment #91)
> For all those playing at home, the change in
> https://phabricator.kde.org/D2986 has now been committed. This makes the
> changes I suggested above as well as completely removing the code identified
> in the perf traces.
> 
> Anyone willing to test master to help confirm the fix and it's lack of side
> effects is extremely welcome.


I have recompiled plasmashell with this patch. Now when copying files plasmashell is not exceeding 4% CPU. When connecting with Wifi network it jumps to 7% for a second. Much better than 25% making cpu fan go crazy.
5.8.4 on Arch
I hope there are no side effects.

Please backport it to 5.8 if possible.

well done Lindsay Roberts et al.

+1 for backporting after field testing, this is an especially visible
and annoying bug and the LTS is obviously going to be around a long
time on opensuse etc.



On 10 December 2016 at 12:48, Piotr Kloc <bugzilla_noreply@kde.org> wrote:
> https://bugs.kde.org/show_bug.cgi?id=356479
>
> --- Comment #104 from Piotr Kloc <pepko94@gmail.com> ---
> (In reply to Lindsay Roberts from comment #91)
>> For all those playing at home, the change in
>> https://phabricator.kde.org/D2986 has now been committed. This makes the
>> changes I suggested above as well as completely removing the code identified
>> in the perf traces.
>>
>> Anyone willing to test master to help confirm the fix and it's lack of side
>> effects is extremely welcome.
>
>
> I have recompiled plasmashell with this patch. Now when copying files
> plasmashell is not exceeding 4% CPU. When connecting with Wifi network it jumps
> to 7% for a second. Much better than 25% making cpu fan go crazy.
> 5.8.4 on Arch
> I hope there are no side effects.
>
> Please backport it to 5.8 if possible.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

This change has now been in master for two months with no reports of regression; I now think backporting is a reasonable step. Specifically because of its impact on laptops and other battery powered machines -- being on battery and having some kind of connecting icon in the tray are highly correlated.

Will leave it up to one of the more authoritative KDE devs to determine whether it is tested enough and significant enough.

Same here, been running with this patch backported to 5.8.x for quite some time, no issues.

*** Bug 373501 has been marked as a duplicate of this bug. ***

I run Gentoo with Plasma 5.8.3 and problem still exists. plasma-workspace is patched with plasma-workspace-5.8.3-systray-cpuload.patch, but it seems like it does not work for me.

My father's desktop PC is running OpenSUSE Leap 42.2 with Plasma 5.8. The CPU usage is low, but when drawing file selection rectangle on Plasmashell window or hovering file, then CPU usage is jumped to 50%. File selection updates to slow and mouse can hover on file, but another file(previously hovered) is highlighted.

Also affects

'Linux 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux' and 'plasma-workspace' version 4:5.8.2-1

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844707

Thanks for the patch! Hope Debian pulls in the changes. This is a serious battery drainer on laptops.

For the record, I had the same issue with tray icons and CPU usage with Plasma 5.8.4 from Debian sid before applying the patch from <https://phabricator.kde.org/D2986> locally. I've been running a patched build for the last four days and I've not experienced any unintended side-effects.

I imagine downstream will be more likely to adopt the patch once it becomes part of Plasma 5.8.6. (It doesn't seem like it made it to 5.8.5, sadly.)

Patch has now been backported to the Plasma/5.8 branch.

*** Bug 374176 has been marked as a duplicate of this bug. ***

On "plasmashell 5.9.3" right now, same problem as descripted in other reports. When copying or extrating files, plasmashell takes 25% of the CPU power (intel i7-u).

Running KDE neon (intel integrated graphics)...

I have Plasma 5.8.5 (Kubuntu) and the issue exists: then there is some animation in the task bar the process plasmashell "eats" all CPU.

Can we re-open this bug ?

(In reply to Sven from comment #115)
> On "plasmashell 5.9.3" right now, same problem as descripted in other
> reports. When copying or extrating files, plasmashell takes 25% of the CPU
> power (intel i7-u).
> 
> Running KDE neon (intel integrated graphics)...

I don't know why nobody from KDE don't want to talk about that "file operations" and cpu usage. Btw, im using plasma 5.8.6 and animated icons in tray still causing high cpu load.

Well, they say it was fixed:
https://phabricator.kde.org/R120:749f60b89f4a166833fb64a5b593a801f63f9615

but in which Plasma release we'll get that patch - I don't know.
According to tags in the link above, it's gonna be next releases:

v5.9.4, v5.9.3, v5.9.2, v5.9.1, v5.9.0, v5.8.95

So, stay tuned !

(In reply to Dmitriy from comment #118)
> Well, they say it was fixed:
> https://phabricator.kde.org/R120:749f60b89f4a166833fb64a5b593a801f63f9615
> 
> but in which Plasma release we'll get that patch - I don't know.
> According to tags in the link above, it's gonna be next releases:
> 
> v5.9.4, v5.9.3, v5.9.2, v5.9.1, v5.9.0, v5.8.95
> 
> So, stay tuned !

The patch is part of 5.8.6 and it does apparently not help:

https://bugzilla.opensuse.org/show_bug.cgi?id=1016920

IMO that's enough confirmation to reopen this issue.

Some info from mine side:

Then my skype app losts its connection it shows rotating icon in system tray area and it makes the plasma consume cpu.

The same happens with Wifi icon then NetworkManager tries to connect to some router -- it shows "loading icon" and Plasma consumes whole CPU (one of them).

As mentioned in comment #90 there are several issues lumped together in this bug. The one that this bug was supposed to be about has long been fixed, it is in >=5.8.6 and >=5.9.0.

The file transfer cpu load bug is a different one.

This bug should be re-open. KDE 5.9.4 and all previous.

Plasma uses 100% CPU (Intel Core i7-2670QM) load, when there is an any animation in the task bar or system tray.

This cause only when i switch to Nvidia Prime card (notebook with Nvidia Optimus). When I switch back to Intel integrated graphics - everything is fine. So several years already I can not use Nvidia card with KDE desktop :(

As mentioned in comment #92 and by Andreas above, high CPU usage whilst copying is tracked in (the still open) https://bugs.kde.org/show_bug.cgi?id=312919 . Please retarget downstream dependency issues around copying onto that.

(In reply to Dreyk from comment #122)
> This cause only when i switch to Nvidia Prime card (notebook with Nvidia 
> Optimus). When I switch back to Intel integrated graphics - everything is fine. 
> So several years already I can not use Nvidia card with KDE desktop :(

If there is an Nvidia specific problem causing high CPU usage for systray animations, I think it warrants a new issue. The fix in this item solved this for all other cases I've heard, and an Nvidia specific problem would require a new investigation and a new fix, and almost certainly doesn't invalidate the fix done here.

I have integrated Intel HD3*** video card and experience this problem. It doesn't seem like Nvidia-specific problem.

See comment #90

We have about 3 different bugs all merged into one here, which is partly why we haven't moved this much.

We have:
1) The heavy kiconloader usage when using an SNI which is updating constantly 

2) We have the extreme number of pointless X messages causing us to spend lots of CPU time in nativeEventFilter (and thus strcmp)

3) Any other GL related delays stuff, such as (hopefully now gone) NVidia busy loop waiting for vsync.


Lets keep this bug as (1) and can close with https://phabricator.kde.org/D2986

I will reopen as 370003 issue for (2) and track that there.

For that reason, when this is merged if you still have high CPU, please don't reopen this as it's probably a different cause.

*** Bug 378316 has been marked as a duplicate of this bug. ***

I had problem that plasmashell was utilizing CPU a lot during tray icon animations (e.g., dropbox sync, copying files via konqueror). I was very frustrated and thinking about leaving KDE. But today I found out that I had running approx 5 panels. 5 running panels were caused by the fact that when I migrate laptop from room to room in work and connect LED TV to present something sometimes panel just disappeared and I had to manually add new one. I did "right click -> Panel Options -> Remove this Panel" on all panels (they were overlay-ed) and started one new panel. After this CPU utilization by plasmashell is OK and doesn't cause slowness of whole system.

I had problem that plasmashell was utilizing CPU a lot during tray icon animations (e.g., dropbox sync, copying files via konqueror). I was very frustrated and thinking about leaving KDE. But today I found out that I had running approx 5 panels. 5 running panels were caused by the fact that when I migrate laptop from room to room in work and connect LED TV to present something sometimes panel just disappeared and I had to manually add new one. I did "right click -> Panel Options -> Remove this Panel" on all panels (they were overlay-ed) and started one new panel. After this CPU utilization by plasmashell is OK and doesn't cause slowness of whole system.

Plasma 5.11.1 openSUSE Tumbleweed
Same issue here - while copying via Dolphin the spinning notification animation kills the CPU - 100%
Workaround 1 - use console/mc
Workaround 2 - turn off notification (progress can man see at the task manager (if enabled) but cannot stop.
Workaround 3 - put the notification tray on an auto-hidden panel.
For now I use combination of 1 and 3.

THanks for the hint with the hidden panel. This really reduces CPU load to zero.

My system is Optimus based laptop (Intel HD4600 and nVidia GTX 860).
I don't use Bumblebee but prime-switch feature.
The high cpu load during file operations notification progress (the wheel is spinning like crazy!!) is showing only while using nVidia card.
If I switch to Intel - no cpu load issue - the wheel is spinning slow.

(In reply to robspamm from comment #130)
> THanks for the hint with the hidden panel. This really reduces CPU load to
> zero.

Second tip - open tray's settings and set the notification option to hidden.
This way the panel can stay and you still have access to file operations progress via opening the tray list.

I'm having the same problem (plamashell v 5.8.7) which seems to be caused by the bluetooth icon in the system tray.
I set the icon to hidden and things seem OK now
(openSUSE 42.3, Plasma 5.8.7)

This issue persists in plasmashell 5.12.4 + 

I consistently see 100% CPU usage of plasmashell while the Ethernet connection is waiting for DHCP (which happens to take a long time on my network) and there's a corresponding panel animation in the NetworkManager icon.

Running Fedora 28 beta, plasma-workspace-5.12.4-1.fc28.x86_64.rpm, plasma-nm-5.12.4-1.fc28.x86_64.rpm, Intel UHD Graphics 620 GPU.

Comment #90 asks not to reopen this bug. How to proceed?

this bug still persists in kubuntu 17.10, kde 5.10.5

this bug still persists in kubuntu 17.10, kde 5.10.5

The bug still persists in KDE neon. And Kubuntu 18.04. as of August 3,  2018

I am using KDE plasma 5.13.4.

Comment #90 asks to not reopen this bug as it is being resolved in other bug reports. These have been marked as resolved or they are inactive since 2016:  https://bugs.kde.org/show_bug.cgi?id=312919 and https://phabricator.kde.org/D2986. As that comment is from 2 years ago and still nothing has been fixed or gotten better by disabling animations (actually worse, as there are now more animations) I reopened this bug.

If there are several errors that need to be fixed for this problem, then either these errors should all be fixed here or 3 new valid bug reports should be opened. If there is no one taking care of this problem, then this should be stated here so that someone can take over ;).

The patches don't help all the systems. The bug affects all animations in systray, desktop widgets, taskbar, and menu. 

This has been around since more than 3 years for me. I am willing to help to resolve this bug creating reports etc... . If this is about nvidia cards, this should get a pretty high priority as it probably affects quite a few people.

Sorry, one more thing: just to be clear why I reopened this bug:  this is NOT just about the file transfer. This is about any animation in the taskbar or system tray or widgets such as starting a new application (also includes any sort of file transfer of course or a simple download with the webbrowser).

See comment #90.

If you have new information, please make a new bug.

After years bug is comeback.
This time on Manjaro Linux (hardware: VMware Workstation 15.0.2) immediately after upgrading QT version from 5.12.1 to 5.12.2. More simply, after this update (on Manjaro KDE edition): https://forum.manjaro.org/t/stable-update-2019-03-29-kernels-gnome-libreoffice-mesa-budgie-browsers-qt/80902

Same behavior

From inxi:
Graphics:
Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.15.0.0 bus ID: 00:0f.0 
Display: x11 server: X.Org 1.20.4 driver: vmware tty: N/A 
OpenGL: renderer: SVGA3D; build v: 3.3 Mesa 18.3.5 direct render: Yes 

Additional Info: https://forum.manjaro.org/t/stable-update-2019-03-29-kernels-gnome-libreoffice-mesa-budgie-browsers-qt/80902/229?u=dreyk

I have exactly the same problem as Dreyk

Ubuntu 19.04
plasmashell 5.16.5
Qt 5.12.4
The bug was encountered while copying files on usb flash drive

This problem was gone for me by setting QSG_RENDER_LOOP=basic as environment variable. It looks like a QT bug, not a Plasma bug.

Review this article for more information:
https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html