Bug 356479 - plasmashell uses 100% CPU when there is an animation in the task bar
Summary: plasmashell uses 100% CPU when there is an animation in the task bar
Status: CLOSED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Manjaro Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
: 336274 351448 357597 363909 364061 364518 365215 371844 371853 373501 374176 378316 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-10 18:58 UTC by AnAkkk
Modified: 2020-08-04 21:09 UTC (History)
85 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Patch to confirm cause (1.54 KB, patch)
2016-07-28 11:18 UTC, Fabian Vogt
Details
Spinner rotating and eating CPU despite network being connected (8.20 KB, image/png)
2016-07-29 18:14 UTC, Damian Kaczmarek
Details
attachment-24892-0.html (1.63 KB, text/html)
2016-07-30 06:01 UTC, nicholas
Details
Perf report while plasmashell running at 100% (6.92 KB, text/plain)
2016-08-01 13:09 UTC, Samantha McVey
Details
strace of plasmashell (270.87 KB, application/gzip)
2016-08-01 13:10 UTC, Samantha McVey
Details
attachment-28198-0.html (1.16 KB, text/html)
2016-08-01 14:40 UTC, nicholas
Details
attachment-8670-0.html (1.16 KB, text/html)
2016-10-02 09:54 UTC, nicholas
Details
attachment-15218-0.html (2.22 KB, text/html)
2016-10-02 12:28 UTC, Larpon
Details
attachment-19338-0.html (1.42 KB, text/html)
2016-10-02 13:38 UTC, Larpon
Details
attachment-26268-0.html (1.11 KB, text/html)
2016-11-29 16:09 UTC, Simone Gaiarin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description AnAkkk 2015-12-10 18:58:43 UTC
Every time that octopi scans for updates and octopi-notifier shows that updates are available, plasmashell CPU usage slowly rise until it uses 100% of the CPU. 
This is very annoying and also causes my mouse to jump until I kill octopi-notifier which makes the CPU usage back to 0%.

Also reported here:
https://github.com/aarnt/octopi/issues/142

I'm now on Plasma 5.5, and the issue is still the same.

Reproducible: Always
Comment 1 AnAkkk 2015-12-25 19:35:30 UTC
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.
Comment 2 AnAkkk 2015-12-25 19:39:19 UTC
I added two issues which seem related. Maybe https://bugs.kde.org/show_bug.cgi?id=351923 is also related?
Comment 3 Kai Uwe Broulik 2016-01-07 16:35:41 UTC
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.
Comment 4 AnAkkk 2016-01-07 16:38:02 UTC
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
Comment 5 David Edmundson 2016-01-19 23:06:07 UTC
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.
Comment 6 David Edmundson 2016-01-20 09:09:52 UTC
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
Comment 7 David Edmundson 2016-01-20 09:54:25 UTC
Note whilst I can still remember. 

xcb_generic_event_t.response_type == 
102
103
Comment 8 AnAkkk 2016-01-27 00:20:32 UTC
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.
Comment 9 AnAkkk 2016-01-27 09:35:13 UTC
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.
Comment 10 Olivier Churlaud 2016-02-02 12:22:05 UTC
I had the same thing:

My connection got lost, and plasmashell used >100%CPU until I disable/enable the connection.
Comment 11 David Edmundson 2016-02-09 09:54:48 UTC
*** Bug 357597 has been marked as a duplicate of this bug. ***
Comment 12 AnAkkk 2016-02-23 14:27:07 UTC
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...
Comment 13 Friedrich W. H. Kossebau 2016-02-28 18:42:34 UTC
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).
Comment 14 Piotr Dobrogost 2016-03-02 17:55:10 UTC
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...
Comment 15 AnAkkk 2016-03-02 19:42:59 UTC
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.
Comment 16 kde2eran 2016-03-27 18:47:50 UTC
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).
Comment 17 Manuel Bärenz 2016-04-17 08:29:04 UTC
Persists in Plasma 5.6.2 with framework 5.18.0 (Gentoo).
Comment 18 Friedrich W. H. Kossebau 2016-04-20 21:38:56 UTC
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" :(
Comment 19 miku84 2016-04-28 18:46:32 UTC
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.
Comment 20 Jan Pavlicek 2016-05-02 14:51:48 UTC
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.
Comment 21 robspamm 2016-05-12 05:32:51 UTC
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.
Comment 22 Foued 2016-05-12 09:53:29 UTC
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...
Comment 23 Foued 2016-05-12 14:05:14 UTC
Still have 60 % with plasma 5.6.4...
Comment 24 Martin Kyral 2016-05-14 22:50:56 UTC
Confirming. konversation blinking icon eats a lot of CPU time.
Comment 25 object909 2016-05-22 17:07:02 UTC
Same problem arch, plasma 5.6.4.
Fixible by using xf86-video-intel with mesa-libgl.
Comment 26 robspamm 2016-05-24 19:15:29 UTC
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.
Comment 27 Foued 2016-05-25 08:53:45 UTC
Same question here, I have the 2 packages you told us but I still have the problem (and a lot more)...
Comment 28 Olivier Churlaud 2016-05-25 17:16:05 UTC
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..
Comment 29 David Edmundson 2016-05-25 17:52:05 UTC
Does running:

QSG_DISTANCEFIELD_ANTIALIASING=subpixel-lowq plasmashell

make a difference?
Comment 30 Olivier Churlaud 2016-05-25 19:19:00 UTC
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)
Comment 31 Olivier Churlaud 2016-05-30 17:50:42 UTC
Since last qt5-base update (5.6.0-6 on archlinux) it seems to be corrected.

Could you confirm?
Comment 32 Piotr Dobrogost 2016-05-30 19:51:04 UTC
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?
Comment 33 Foued 2016-05-30 20:16:36 UTC
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.
Comment 34 Foued 2016-05-31 07:26:32 UTC
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 :(
Comment 35 Foued 2016-06-01 09:29:38 UTC
Same thing with 5.6.0-7 :(
Comment 37 Foued 2016-06-02 08:20:51 UTC
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 ?
Comment 38 wcramer 2016-06-03 09:36:19 UTC
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.
Comment 39 Piotr Dobrogost 2016-06-03 16:27:32 UTC
(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.
Comment 40 wcramer 2016-06-03 17:50:37 UTC
(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?
Comment 41 miku84 2016-06-05 19:08:54 UTC
The issue still exists after recreating the panel.
Comment 42 Olivier Churlaud 2016-06-05 19:16:41 UTC
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
Comment 43 AnAkkk 2016-06-09 18:03:30 UTC
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?
Comment 44 Damian Kaczmarek 2016-06-16 21:00:54 UTC
This bug is driving up my CPU temperature to 95°...
Comment 45 AnAkkk 2016-06-19 10:23:48 UTC
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.
Comment 46 kikadf 2016-06-20 15:44:07 UTC
Same issue on Plasma 5.6.5.1 with KF 5.22.0. 
i3 CPU, 70-80 % usage, 80 C warm....
Comment 47 Tim Schlotfeldt 2016-07-17 11:03:11 UTC
Same here on a laptop with i5 CPU, intel graphics, KDE 5.7.1 on Arch Linux.
Comment 48 Jos van den Oever 2016-07-27 07:46:27 UTC
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
Comment 49 Jos van den Oever 2016-07-27 08:05:46 UTC
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.
Comment 50 nicholas 2016-07-27 17:04:10 UTC
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?
Comment 51 Jos van den Oever 2016-07-27 20:32:54 UTC
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.
Comment 52 Jos van den Oever 2016-07-27 21:23:40 UTC
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
Comment 53 Fabian Vogt 2016-07-28 11:18:12 UTC
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.
Comment 54 nicholas 2016-07-28 13:19:24 UTC
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)
Comment 55 Damian Kaczmarek 2016-07-29 18:14:24 UTC
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.
Comment 56 Trevor Parsons 2016-07-30 01:21:33 UTC
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.
Comment 57 nicholas 2016-07-30 06:01:48 UTC
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.
>
Comment 58 Samantha McVey 2016-08-01 13:09:01 UTC
Created attachment 100406 [details]
Perf report while plasmashell running at 100%

Here is perf which I ran against plasmashell.
Comment 59 Samantha McVey 2016-08-01 13:10:14 UTC
Created attachment 100407 [details]
strace of plasmashell

Here is an strace.
Comment 60 nicholas 2016-08-01 14:40:09 UTC
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.
>
Comment 61 Samantha McVey 2016-08-01 14:43:53 UTC
(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.
Comment 62 David Edmundson 2016-08-02 21:17:10 UTC
*** Bug 364518 has been marked as a duplicate of this bug. ***
Comment 63 David Edmundson 2016-08-02 22:32:21 UTC
*** Bug 365215 has been marked as a duplicate of this bug. ***
Comment 64 Robby Pedrica 2016-08-03 07:17:33 UTC
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.
Comment 65 David Edmundson 2016-08-16 12:27:54 UTC
*** Bug 363909 has been marked as a duplicate of this bug. ***
Comment 66 David Edmundson 2016-08-16 12:41:19 UTC
*** Bug 364061 has been marked as a duplicate of this bug. ***
Comment 67 Larpon 2016-08-17 21:43:34 UTC
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
Comment 68 Simone Gaiarin 2016-08-25 20:50:37 UTC
What is the modification to NotificationIcon.qml mentioned by Nicholas? I've the same problem especially for copying file over the network,
Comment 69 Simone Gaiarin 2016-08-25 20:57:47 UTC
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
Comment 70 nicholas 2016-08-26 05:29:05 UTC
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
Comment 71 David Edmundson 2016-08-26 16:11:25 UTC
*** Bug 351448 has been marked as a duplicate of this bug. ***
Comment 72 Simone Gaiarin 2016-10-02 08:57:26 UTC
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).
Comment 73 Andreas Sturmlechner 2016-10-02 09:02:10 UTC
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.
Comment 74 Fabian Vogt 2016-10-02 09:02:21 UTC
(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.
Comment 75 nicholas 2016-10-02 09:13:56 UTC
(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.
Comment 76 nicholas 2016-10-02 09:15:25 UTC
(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.
Comment 77 Fabian Vogt 2016-10-02 09:23:35 UTC
(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.
Comment 78 Simone Gaiarin 2016-10-02 09:49:08 UTC
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?
Comment 79 AnAkkk 2016-10-02 09:51:59 UTC
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.
Comment 80 nicholas 2016-10-02 09:54:29 UTC
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.
>
Comment 81 Fabian Vogt 2016-10-02 09:57:05 UTC
(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
Comment 82 Larpon 2016-10-02 12:28:49 UTC
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.
>
Comment 83 Simone Gaiarin 2016-10-02 13:22:00 UTC
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
Comment 84 Larpon 2016-10-02 13:38:15 UTC
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.
>
Comment 85 Damian Kaczmarek 2016-10-03 02:48:37 UTC
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.
Comment 86 Larpon 2016-10-03 10:22:53 UTC
Popping by again just to say that I haven't got Skype or Spotify on my system
Comment 87 Lindsay Roberts 2016-10-06 18:29:04 UTC
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.
Comment 88 Damian Kaczmarek 2016-10-06 19:22:54 UTC
@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.
Comment 89 Lindsay Roberts 2016-10-07 04:49:15 UTC
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)
Comment 90 David Edmundson 2016-10-09 23:40:20 UTC
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.
Comment 91 Lindsay Roberts 2016-10-10 18:54:44 UTC
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.
Comment 92 Lindsay Roberts 2016-10-13 18:59:24 UTC
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.
Comment 93 cristiano04 2016-10-22 23:00:58 UTC
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.
Comment 94 cristiano04 2016-10-22 23:01:52 UTC
On a side note, pausing the transfer does not stop the animation (it should).
Comment 95 Rex Dieter 2016-10-23 03:47:26 UTC
> Did the patchset make it to 5.8.2? 

No, only master branch (which will become 5.9) so far.
Comment 96 Igor Tarasov 2016-10-29 12:41:54 UTC
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.
Comment 97 David Edmundson 2016-10-30 21:22:34 UTC
*** Bug 371844 has been marked as a duplicate of this bug. ***
Comment 98 David Edmundson 2016-10-30 21:22:47 UTC
*** Bug 371853 has been marked as a duplicate of this bug. ***
Comment 99 Rex Dieter 2016-11-03 19:06:52 UTC
*** Bug 336274 has been marked as a duplicate of this bug. ***
Comment 100 Wulf Bolte 2016-11-29 12:48:32 UTC
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... :(
Comment 101 Jos van den Oever 2016-11-29 15:44:43 UTC
For me it's fixed since Plasma 5.8.
Comment 102 Simone Gaiarin 2016-11-29 16:09:10 UTC
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.
Comment 103 retired 2016-12-03 22:30:03 UTC
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
Comment 104 retired 2016-12-10 11:48:44 UTC
(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.
Comment 105 nicholas 2016-12-10 13:01:41 UTC
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.
Comment 106 Lindsay Roberts 2016-12-11 01:05:29 UTC
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.
Comment 107 Andreas Sturmlechner 2016-12-12 10:23:45 UTC
Same here, been running with this patch backported to 5.8.x for quite some time, no issues.
Comment 108 Christoph Feck 2016-12-13 01:33:57 UTC
*** Bug 373501 has been marked as a duplicate of this bug. ***
Comment 109 Branko 2016-12-13 13:43:31 UTC
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.
Comment 110 Lach Sławomir 2016-12-23 11:36:32 UTC
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.
Comment 111 Manas 2016-12-25 17:47:18 UTC
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.
Comment 112 Iris Morelle 2016-12-27 21:53:59 UTC
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.)
Comment 113 Lindsay Roberts 2016-12-30 18:27:38 UTC
Patch has now been backported to the Plasma/5.8 branch.
Comment 114 Christoph Feck 2016-12-31 21:35:31 UTC
*** Bug 374176 has been marked as a duplicate of this bug. ***
Comment 115 Sven 2017-03-15 13:03:40 UTC
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)...
Comment 116 Dmitriy 2017-03-24 09:55:45 UTC
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 ?
Comment 117 Branko 2017-03-24 11:45:10 UTC
(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.
Comment 118 Dmitriy 2017-03-24 11:59:19 UTC
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 !
Comment 119 Fabian Vogt 2017-03-24 12:19:25 UTC
(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.
Comment 120 Dmitriy 2017-03-24 12:26:33 UTC
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).
Comment 121 Andreas Sturmlechner 2017-03-24 12:31:18 UTC
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.
Comment 122 Dreyk 2017-03-25 16:33:45 UTC
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 :(
Comment 123 Lindsay Roberts 2017-03-25 17:26:48 UTC
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.
Comment 124 Dmitriy 2017-03-25 17:30:27 UTC
I have integrated Intel HD3*** video card and experience this problem. It doesn't seem like Nvidia-specific problem.
Comment 125 David Edmundson 2017-03-25 18:47:16 UTC
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.
Comment 126 Jan Grulich 2017-05-09 08:11:19 UTC
*** Bug 378316 has been marked as a duplicate of this bug. ***
Comment 127 juraj 2017-09-05 15:16:47 UTC
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.
Comment 128 juraj 2017-09-05 15:17:04 UTC
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.
Comment 129 Marcin Ciosek 2017-10-26 21:38:10 UTC
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.
Comment 130 robspamm 2017-10-29 08:23:37 UTC
THanks for the hint with the hidden panel. This really reduces CPU load to zero.
Comment 131 Marcin Ciosek 2017-11-01 21:16:43 UTC
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.
Comment 132 Marcin Ciosek 2017-11-02 18:54:16 UTC
(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.
Comment 133 Alan Prescott 2018-01-16 08:47:57 UTC
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)
Comment 134 kde2eran 2018-04-10 04:44:47 UTC
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?
Comment 135 Adam Felson 2018-07-18 19:46:09 UTC
this bug still persists in kubuntu 17.10, kde 5.10.5
Comment 136 Adam Felson 2018-07-18 19:46:53 UTC
this bug still persists in kubuntu 17.10, kde 5.10.5
Comment 137 Thomas.Meschede 2018-08-03 19:53:13 UTC
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.
Comment 138 Thomas.Meschede 2018-08-03 19:58:58 UTC
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).
Comment 139 David Edmundson 2018-08-04 12:01:37 UTC
See comment #90.

If you have new information, please make a new bug.
Comment 140 Dreyk 2019-04-03 07:38:24 UTC
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
Comment 141 Sergey 2019-11-21 19:59:31 UTC
I have exactly the same problem as Dreyk
Comment 142 Sergey 2019-11-21 20:06:36 UTC
Ubuntu 19.04
plasmashell 5.16.5
Qt 5.12.4
The bug was encountered while copying files on usb flash drive
Comment 143 Jose Angel Pastrana 2020-04-02 13:07:53 UTC
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