Bug 311799 - Notification progress indicator makes Xorg eat up CPU
Summary: Notification progress indicator makes Xorg eat up CPU
Status: RESOLVED UPSTREAM
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: 5.4.2
Platform: unspecified Linux
: NOR major
Target Milestone: 1.0
Assignee: Martin Klapetek
URL:
Keywords:
: 312170 318127 320472 342226 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-16 19:58 UTC by Kai Uwe Broulik
Modified: 2022-09-29 23:45 UTC (History)
32 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
extract from xsession-errors (german) (2.87 KB, text/plain)
2013-05-13 17:38 UTC, Julian Kalinowski
Details
Patch for kde-workspace that disables spinning busy icons and avoids CPU-eating (1.01 KB, patch)
2014-12-30 11:59 UTC, Julian Kalinowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Uwe Broulik 2012-12-16 19:58:15 UTC
I was copying a large file (3 GiB) over network, while I was copying, I noticed that Xorg had 25% CPU usage on my system (4 cores, which means one core was 100% used). When I cancelled the copy progress, the CPU usage dropped back to its normal 2-4%. I resumed the copy progress and it started again, so I suspect the new notification tray icon animation to be the cause. It doesn't matter whether I have the plasmoid popup visible or not, or the graph shown or not. It is enough to have that spinning icon.

Reproducible: Always
Comment 1 Luis Zaldivar 2012-12-28 18:02:41 UTC
This one happens to me too. I'm 
Here is an easy way to reproduce it.

Open a magnet link with ktorrent clicking on firefox.

The progress indicator on the notification tray will be kept spining for a long time.
X will eat 100% cpu until you click stop on the progress bar.

Using:
plasma-desktop Version: 4:4.9.95-0ubuntu1~ubuntu12.10~ppa1
xserver-xorg Version: 1:7.7+1ubuntu4
Comment 2 Jekyll Wu 2013-01-13 16:15:12 UTC
*** Bug 312170 has been marked as a duplicate of this bug. ***
Comment 3 Eugene Shalygin 2013-01-18 14:40:27 UTC
I can add that when progress circle showing only spinning ring, CPU usage is not extremely high, but when the circle is starting to fill, then CPU usage jumps to the maximum
Comment 4 Eugene Shalygin 2013-01-18 20:21:16 UTC
When I'm copying files via Dolphin, the same progress indicator does not lead to high CPU usage by Xorg, but when I downlowd files via Konqueror --- Xorg eats CPU
Comment 5 Jaroslav Kameník 2013-03-15 08:41:44 UTC
I have same problem on fresh openSUSE 12.3 with kde 4.10.1. I restored data from backup and after some time desktop became very slow and top showed Xorg using 100% of cpu.
Comment 6 thekthe 2013-03-20 09:12:43 UTC
Same situation here (Kubuntu 12.10 with KDE 4.10.1 on Dell d630 with Intel graphic card) every notification causes spinning ring animation and Xorg cpu usage goes high. Wish there was an option for static image like in previous version.
Comment 7 Rusty Nejdl 2013-04-07 02:03:15 UTC
Same with FreeBSD running 4.10.1 with NVIDIA graphics card.
Comment 8 Jekyll Wu 2013-04-10 13:53:32 UTC
*** Bug 318127 has been marked as a duplicate of this bug. ***
Comment 9 Pascal d'Hermilly 2013-04-10 14:59:33 UTC
why isn't this marked as confirmed yet?
Comment 10 Artur Shaihullin 2013-04-14 18:18:56 UTC
The same here. Starting upload with krusader and XOrg load 100% of cpu. (
Comment 11 Jaroslav Kameník 2013-04-15 09:28:26 UTC
I upgraded to 4.10.2 and it seems to be good. But it is still very slow. When I mount remote drive with smb and copy data with midnight commander, it does 20-30MB/s, when I open it in dolphin and copy, it's bellow 5MB/s.
Comment 12 Vincent Petry 2013-04-16 19:23:26 UTC
Xorg is eating up CPU for me as well while the notifications spinner is running. This makes KDE very slow when switching desktops as well.

This is on openSUSE 12.3 x86_64 with KDE 4.10.0
Comment 13 ffmeat 2013-04-28 17:04:48 UTC
I have same bug (OpenSuse 12.4 x86, KDE 4.10.2).
And I've a workaround: disable "Notifications" in system tray settings and then add "Notifications" widget.
Comment 14 Andrew 2013-05-02 11:50:14 UTC
*** This bug has been confirmed by popular vote. ***
Comment 15 Andrew 2013-05-02 11:58:55 UTC
Just a spinning ring gives +10% for X and plasma-desktop processes at Intel i5-2540M.
I have also Sempron 3000+ machine and things are quite worse there.

Static indicator could be a workaround, as for me.

KDE 4.10.2, Fedora 18 x64
Comment 16 Julian Kalinowski 2013-05-13 16:53:28 UTC
Workaround in comment #13 doesn't work for me, as the notifications widget also has a spinning circle which eats up CPU.

Really bad bug, as the system is very unresponsive...
Comment 17 Julian Kalinowski 2013-05-13 17:38:11 UTC
Created attachment 79874 [details]
extract from xsession-errors (german)

My workaround is to disable the spinning animation in:
/usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/NotificationIcon.qml
Search for "running: visible" and set it to false.
Comment 18 Julian Kalinowski 2013-05-13 17:40:05 UTC
Comment on attachment 79874 [details]
extract from xsession-errors (german)

>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:166: TypeError: Result of expression 'jobsSource.data[modelD
ata]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:125: TypeError: Result of expression 'jobsSource.data[modelD
ata]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:108: TypeError: Result of expression 'jobsSource.data[modelD
ata]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:88: TypeError: Result of expression 'jobsSource.data[modelDa
ta]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:78: TypeError: Result of expression 'jobsSource.data[modelDa
ta]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:72: TypeError: Result of expression 'jobsSource.data[modelData]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:60: TypeError: Result of expression 'jobsSource.data[modelData]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:54: TypeError: Result of expression 'jobsSource.data[modelData]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:37: TypeError: Result of expression 'jobsSource.data[modelData]' [undefined] is not an object.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/main.qml:139:9: QML Flickable: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/main.qml:139:9: QML Flickable: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:70:13: QML Text: Bei der fÃ<U+0083>ür die Eigenschaft âÃ<U+0080>Ã<U+009E>widthâÃ<U+0080>Ã<U+009C> angegebenen 
>Bindung wurde eine Endlosschleife festgestellt
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/Jobs.qml:101:19: QML JobDelegate: Bei der fÃ<U+0083>ür die Eigenschaft âÃ<U+0080>Ã<U+009E>heightâÃ<U+0080>Ã<U+009C> 
>angegebenen Bindung wurde eine Endlosschleife festgestellt
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/Jobs.qml:101:19: QML JobDelegate: Bei der fÃ<U+0083>ür die Eigenschaft âÃ<U+0080>Ã<U+009E>heightâÃ<U+0080>Ã<U+009C> 
>angegebenen Bindung wurde eine Endlosschleife festgestellt
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/main.qml:139:9: QML Flickable: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
>file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/main.qml:139:9: QML Flickable: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
>plasma-desktop(19121)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
>plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:189:21: QML TextEdit: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
>plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:143:13: QML Item: Bei der fÃ<U+0083>ür die Eigenschaft âÃ<U+0080>Ã<U+009E>heightâÃ<U+0080>Ã<U+009C> angegebenen Bindung wurde eine 
>Endlosschleife festgestellt
>plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:143:13: QML Item: Bei der fÃ<U+0083>ür die Eigenschaft âÃ<U+0080>Ã<U+009E>heightâÃ<U+0080>Ã<U+009C> angegebenen Bindung wurde eine 
>Endlosschleife festgestellt
>plasmapackage:/ui/NotificationDelegate/NotificationDelegate.qml:143:13: QML Item: Bei der fÃ<U+0083>ür die Eigenschaft âÃ<U+0080>Ã<U+009E>heightâÃ<U+0080>Ã<U+009C> angegebenen Bindung wurde eine 
>Endlosschleife festgestellt
>file:///usr/lib64/kde4/imports/org/kde/plasma/components/TabBar.qml:150:5: QML Item: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
>file:///usr/lib64/kde4/imports/org/kde/plasma/components/TabBar.qml:150:5: QML Item: Bei der FÃ<U+0083>ülloperation wurde eine potentielle Endlosschleife der Anker festgestellt.
Comment 19 Kai Uwe Broulik 2013-05-13 20:36:26 UTC
At least that one:
file:///usr/share/apps/plasma/plasmoids/org.kde.notifications/contents/ui/JobDelegate.qml:166: TypeError: Result of expression 'jobsSource.data[modelData]' [undefined] is not an object.

has been fixed recently by checking whether data[modelData] is defined. Don't think that has an impact on this bug though.
Comment 20 DimanNe 2013-06-06 10:15:20 UTC
I have same bug on two computers
both kubuntu 13.04, kde 4.10.3
Comment 21 Michael D 2013-06-06 16:32:46 UTC
Bug confirmed in KDE 4.10.3, Kubuntu 13.04, mainline kernel 3.9.4. A workaround to get Xorg usage down is to do what is described in comment #13, but plasma-desktop and kwin usage still remain unreasonably high (together around 30% of my Core i5).
Comment 22 Kevin Funk 2013-07-01 18:29:33 UTC
Raising importance. This is a major issue. It renders the desktop completely useless.
Comment 23 Julian Kalinowski 2013-07-10 07:30:48 UTC
This seems to be fixed.
At least for me, in KDE 4.10.4, CPU usage of plasma-desktop is at 8% (still too high for updating an icon i think) while X's usage is barely increased while copying a file and watching the spinning notification icon.

Can somebody confirm this?
Comment 24 DimanNe 2013-07-10 08:58:37 UTC
No, this is not fixed yet.
Still use very much cpu and freeze.
(Just leave psi with unread message for a night)
Comment 25 Andrew 2013-07-10 09:40:21 UTC
(In reply to comment #24)
> (Just leave psi with unread message for a night)
Just in case, it can be tested with following:
    kdialog --passivepopup test

As for me, the main problem is that PC becomes slow after a long spinning time. Consequences are still present after you clear the notifications list.
Not sure what it is related with—KDE, xorg, video driver... However it's reproduced at two machines with different HW, so the video card should not be related here.
Comment 26 engine.warp 2013-07-11 07:05:21 UTC
Same issue with Fedora 18 and KDE plasma, waiting for the fix.........
Comment 27 Kai Uwe Broulik 2013-07-13 11:56:21 UTC
*** Bug 320472 has been marked as a duplicate of this bug. ***
Comment 28 Andrew 2013-07-14 17:21:43 UTC
(In reply to comment #23)
My results are following. SW: Fedora 19 x64, KDE 4.10.4, kernel 3.9.9. HW: AMD Sempron 3000+ (single core), NVidia 6600 @ Nouveau.
Spinning indicator adds +6% for plasma-desktop process, +8% for the X process and +20% for overall CPU consumption.
Comment 29 DimanNe 2013-07-14 19:41:27 UTC
(In reply to comment #28)

How long was your indicator spinning before you saw "+6% for plasma-desktop process, +8% for the X process"?
It is very important to leave indicator spinning for a long time.
Comment 30 engine.warp 2013-07-15 07:11:17 UTC
my system was getting CPU hungry after let say half an hour from having a notification not dismiss and practically every time right after a resume from suspend or hibernate.
Comment 31 Andrew 2013-07-15 08:57:19 UTC
(In reply to comment #29)
You are right, that are just the immediate results which don't have a significant consequences to UI behaviour. Of course, 20% is too much for the very minor visual effect.
Left for a long time it slows down everything a lot (see comment #25), but I didn't perform the exact measures.
Comment 32 Andrew 2013-07-15 11:54:36 UTC
(In reply to comment #31)
Add: after some time it can consume 1 logical core of Intel i5-2540M almost entirely.
Comment 33 Thomas Lübking 2013-07-25 20:58:53 UTC
Might lead to OOM conditions, ie. leak - see bug #320354
Comment 34 Michael D 2013-09-02 12:57:47 UTC
In KDE 4.11's network management tray widget, the same bug occurs with the spinning dots animation present while connecting to a network. In particular, plasma-desktop, kwin and xorg together eat up a significant chunk of cpu resources while the animation occurs. Like the progress indicator bug here, cpu usage can be greatly reduced by disabling the tray widget and adding an independent widget for network management in the panel instead.

I have not filed a separate bug for this because it appears to be a bug with the system tray and its widget animations, not the network management applet.
Comment 35 Michael D 2013-09-30 14:58:57 UTC
This is certainly an issue with how system tray handles animations. One funny occurrence of this bug I just noticed involves the blinking animation of the battery indicator which occurs while the battery is at critical level. (It's funny because the blinking battery animation is devouring precious battery/cpu resources while the battery is at critical!)

KDE 4.11.1
Comment 36 Kai Uwe Broulik 2013-09-30 15:07:29 UTC
I guess it's a QML thing with a sequential animation. I guess I will remove the animation again. It wastes precious resources and causes fullscreen repaints depending on Tearing prevention settings... :-(
Comment 37 petrk 2014-03-22 15:20:18 UTC
Today I saw thing very similar to this.
I was copying 1.2 GB file from hard drive to android device and 2 of 4 threads were spiking 0-100%.
X was eating around 25% and it calmed down right after finishing task.
Comment 38 Kai Uwe Broulik 2014-06-15 20:30:43 UTC
Git commit 60ddc9f25d75686b56145120096fa741b2b2216f by Kai Uwe Broulik.
Committed on 15/06/2014 at 20:28.
Pushed by broulik into branch 'master'.

Use RotationAnimator for BusyIndicator

This makes the animation run directly on the scene graph to not stress the CPU that much

REVIEW: 118769
Related: bug 336274

M  +2    -2    src/declarativeimports/plasmacomponents/qml/BusyIndicator.qml

http://commits.kde.org/plasma-framework/60ddc9f25d75686b56145120096fa741b2b2216f
Comment 39 Antonio Orefice 2014-10-12 11:50:20 UTC
plasma 4.14.1 and i can't see any improvement.
do we need kde5?
Comment 40 Christoph Feck 2014-12-30 02:36:25 UTC
*** Bug 342226 has been marked as a duplicate of this bug. ***
Comment 41 Julian Kalinowski 2014-12-30 11:58:06 UTC
The patch from comment #38 only affects KDE5, i guess.
I'm running KDE 4.14.3 and also still seeing this bug. The workaround from my comment #17 works, so why not just disable the spinning icon to not eat up a whole core while executing long-running tasks?

Please just DISABLE the damn spinning icon!
I created a patch for kde-workspace KDE/4.11.
Comment 42 Julian Kalinowski 2014-12-30 11:59:21 UTC
Created attachment 90167 [details]
Patch for kde-workspace that disables spinning busy icons and avoids CPU-eating
Comment 43 Nicolas F. 2015-02-17 22:12:54 UTC
I'm seeing similar behaviour on my Plasma 5.2 desktop (ArchLinux); the notification tray icon spins extremely fast. However, not xorg is eating up the CPU, but plasmashell. This happens with the copy notification as well as the network manager applet when connecting to wireless networks.

The core issue, as far as I can tell, is that something is in a busy loop spinning the circle, as opposed to updating it at a fixed interval. If someone feels really adventurous, they might even try updating it at the same frequency as the monitor's refresh rate, but make the animation constant-time.
Comment 44 Nicolas F. 2015-03-02 21:16:37 UTC
I've just recently temporarly switched from an Optimus setup with nvidia's proprietary driver to purely using the Intel GPU. When Just using the intel GPU, the issue doesn't exist. Using nvidia's proprietary drivers in an Optimus setup, the problem does persist.

It's possible that the spinning circle swaps buffers in tandem with the vertical sync, but since the nvidia GPU has no connected outputs there is no delay to wait on, resulting in the bug I see here.
Comment 45 Julian Kalinowski 2015-07-29 09:56:10 UTC
I'm using Intel GPUs on both systems where this error occurs, so this can't be related to nvidia optimus.
One is KDE 4, the other is upgraded to Plasma 5 (Ubuntu 15.04) which still has the same issue (see bug report: https://bugs.kde.org/show_bug.cgi?id=336274)

As long as this problem exists, why can't we just disable the useless spinning icon to save battery power?
Comment 46 Michael D 2015-07-29 10:15:19 UTC
A static symbol can express (some) of what the animation expresses.

It's worth noting that OS X Mavericks disabled the animation for time machine backups to save battery as well. From ArsTechnica: "Apple is so dedicated to saving energy in Mavericks that it has replaced Time Machine’s animated clock-spinning-backwards menu bar icon with a static icon. (An extra arrowhead now appears on the clock icon’s outline when a backup is in progress.) As clever as the animation was, Apple has apparently decided it’s not worth waking the CPU multiple times a second to redraw the menu bar icon whenever Time Machine is running."
Comment 47 Pascal d'Hermilly 2015-07-29 10:49:03 UTC
And file syncing programs such as Owncloud or Dropbox also use a static icon - usually a ring with arrows.
It's easily understood and solves the issue immediately.
Comment 48 Eugene Shalygin 2015-07-29 11:20:39 UTC
Not only the copy progress indicator is animated in Plasma 5. KTp and NetworkManager icons also use animations when connecting or changing state, and these animations eat CPU in the same way. Which is especially ridiculous when the screen is getting locked and KTp starts to spin-up the CPU cooler when nobody needs its stupid animation. Sometimes plasma-nm does not stop animation upon connecting to a network, and because of that plasmashell does not stop to consume a lot of CPU. In such a case restarting the plasmashell does not help, but only logout does.

Your animations, which occupy less than 0.05% of a screen, require more CPU resources than full-screen games! Is there a better way to disgrace oneself as a developer?

If you are unable to implement animations, give us a way to disable them.
Comment 49 Pascal d'Hermilly 2015-07-29 11:24:25 UTC
Please delete comment 48. Insulting the developers should not be accepted.
Comment 50 Michael D 2015-07-29 11:39:17 UTC
I see three options:

(1) Remove the ability for widgets to be animated (probably extreme);

(2) If there are guidelines for developing widgets, state clearly in them that animations should be almost always prohibited unless (i) they provide useful information a static symbol couldn't, and (ii) they terminate quickly;

(3) Give the user an option to disable animations either globally or on a per-widget basis.
Comment 51 Nicolas F. 2015-08-08 18:13:04 UTC
(In reply to Eugene Shalygin from comment #48)
> Not only the copy progress indicator is animated in Plasma 5. KTp and
> NetworkManager icons also use animations when connecting or changing state,
> and these animations eat CPU in the same way. Which is especially ridiculous
> when the screen is getting locked and KTp starts to spin-up the CPU cooler
> when nobody needs its stupid animation. Sometimes plasma-nm does not stop
> animation upon connecting to a network, and because of that plasmashell does
> not stop to consume a lot of CPU. In such a case restarting the plasmashell
> does not help, but only logout does.
> 
> Your animations, which occupy less than 0.05% of a screen, require more CPU
> resources than full-screen games! Is there a better way to disgrace oneself
> as a developer?
> 
> If you are unable to implement animations, give us a way to disable them.

The problem you describe is different from this one it seems; is it by any chance that you use nvidia optimus? If so, this is actually their bug caused by the Qt render loop not getting a proper interval to swap. I've reported this here: https://bugs.kde.org/show_bug.cgi?id=347237 and also upstream at Qt and at nvidia.
Comment 52 Eugene Shalygin 2015-08-08 18:22:13 UTC
(In reply to Nicolas Frattaroli from comment #51)
No, I use Haswell gaphics. But this seems to be Qt problem too, because a simple QML app with BusyIndicator also uses 4--5% CPU. This is terrible...
Comment 53 Sergio Martins 2015-08-12 16:53:51 UTC
(In reply to Eugene Shalygin from comment #52)
> (In reply to Nicolas Frattaroli from comment #51)
> No, I use Haswell gaphics. But this seems to be Qt problem too, because a
> simple QML app with BusyIndicator also uses 4--5% CPU. This is terrible...

Can you open a bug in Qt bug tracker and attach a test-case ?
Comment 54 Kai Uwe Broulik 2015-09-01 18:57:53 UTC
Could also be attributed to QtQuick not doing partial repaints meaning it constantly repaints the entire panel because of the spinny thing.
Comment 55 csabi 2015-09-11 21:32:07 UTC
Hi, just to confirm, I am also having this bug on an Nvidia Optimus video card.
Comment 56 luminoso 2015-10-16 12:50:46 UTC
I confirm this bug. Even with an i7-4710HQ my desktop is almost unusable when copying files.
KDE Frameworks 5.15.0, plasma 5.4.2, KDE Applications 15.08.1. (Fedora 22)

The workaround is to disable "Track file transfers and other jobs" in Notifications Settings
Comment 57 auxsvr 2015-10-16 13:08:33 UTC
Perhaps related to this is that I observed some weeks ago the indicator being updated as fast as the system could support, consuming 100% CPU.
Comment 58 luminoso 2015-10-16 13:11:44 UTC
auxsvr that can make some sense. This old is too hold to still be present unfortunately
Comment 59 Martin Klapetek 2015-10-16 17:56:27 UTC
In Plasma 5.4, the rotating animation is done on your GPU, in the QtQuick SceneGraph directly.

There is a known bug in QtQuick especially wrt Optimus cards where it doesn't cap the rendering at 60fps and basically goes full power at the rendering with about 99% of the cycles wasted.

See https://bugreports.qt.io/browse/QTBUG-45959

I imagine this is similar with other drivers. We can't really do much about it as ultimately this is a bug in upstream (QtQuick/GPU drivers).

What we could do, however, is provide a setting to turn off all animations. This would require fixing all applets to display alternative things instead of those animated ones. If you're interested in that, please follow bug 353974.

I'll close this one as upstream issue as there is nothing we can do about it (besides having that option). Sorry.
Comment 60 jos poortvliet 2015-11-23 09:07:49 UTC
At least for some users this is caused by other things than graphics drivers and Qt bugs, see https://bugs.kde.org/show_bug.cgi?id=336274

For those the good news is that this should fix the problem: https://quickgit.kde.org/?p=plasma-framework.git&a=commit&h=a9d3d9a81ab282298088bf0753c1c77f0ec21afe

Coming to the next Frameworks release. For those not on a rolling release, bug your distro for a backport or - try a rolling release because it is awesome ;-)
Comment 61 Michael D 2016-11-17 09:40:55 UTC
I'm running KDE Neon Dev. Edition (git stable), Frameworks 5.29.0, plasma 5.8.3, and this bug is still present. On my quad-core CPU, top shows plasmashell using 67%, Xorg using 31%, and kwin_x11 using 6%. I'm using the open source Radeon drivers (r600). This would be pretty bad on mobile while running off battery.