Bug 381000 - [Regression] High CPU when background is set to slideshow
Summary: [Regression] High CPU when background is set to slideshow
Status: CLOSED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Image Wallpaper (show other bugs)
Version: 5.10.1
Platform: Archlinux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Marco Martin
URL:
Keywords:
: 361074 381471 382262 382288 382316 382413 382602 382687 383111 385130 385350 385970 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-06-09 02:56 UTC by sparhawk
Modified: 2018-01-24 18:02 UTC (History)
64 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot of blank wallpaper / media frame (134.96 KB, image/png)
2017-07-13 19:18 UTC, Mircea Kitsune
Details
Massif snapshots of the plasmashell process. (213.90 KB, text/plain)
2017-07-17 20:08 UTC, gilaldpellaeon
Details
Massif snapshot w/o eeb320bbd (many pics) (177.33 KB, text/plain)
2017-07-20 09:59 UTC, gilaldpellaeon
Details
Massif snapshot w/o eeb320bbd (2 pics) (173.61 KB, text/plain)
2017-07-20 10:00 UTC, gilaldpellaeon
Details
log output with QT_LOGGING_RULES=qt.scenegraph.renderloop.debug=true (26.52 KB, application/gzip)
2017-07-20 15:06 UTC, TOM Harrison
Details
Massif analysis, QSG_RENDER_LOOP=basic (611.79 KB, text/plain)
2017-07-20 15:55 UTC, gilaldpellaeon
Details
Massif analysis, QSG_RENDER_LOOP=threaded (461.12 KB, text/plain)
2017-07-20 15:56 UTC, gilaldpellaeon
Details
Add debug in QtDeclarative QSGGuiThreadRenderLoop (2.23 KB, patch)
2017-07-23 15:44 UTC, David Edmundson
Details
plasmashell output with qt5-declarative 5.9.1-3 patched with 106799 (2.45 MB, text/x-log)
2017-07-23 17:24 UTC, Thomas Baag
Details
unfortunately still using almost single core on plasmashell (32.19 KB, image/png)
2017-07-25 02:02 UTC, TOM Harrison
Details
callgrind analysis on machine that has such issue. (463.33 KB, application/gzip)
2017-07-25 02:37 UTC, TOM Harrison
Details
gdb.txt (12.90 KB, text/plain)
2017-08-08 01:45 UTC, rооt
Details
gdb.txt from laptop with Intel graphic card. (2.52 KB, application/gzip)
2017-08-08 02:05 UTC, TOM Harrison
Details
gdb.txt with newer information. (56.42 KB, application/gzip)
2017-08-08 10:32 UTC, TOM Harrison
Details
gdb.txt (13.57 KB, application/x-xz)
2017-08-08 11:16 UTC, rооt
Details
strace of kwin_x11 (60.10 KB, text/plain)
2017-08-18 12:45 UTC, Vova Mshanetskiy
Details
Bug demonstration using qmlscene (1002 bytes, text/x-qml)
2017-10-30 12:28 UTC, Vova Mshanetskiy
Details
Output of 108642 with QSG_INFO=1 on affected system (6.71 KB, text/plain)
2017-11-08 12:35 UTC, Vova Mshanetskiy
Details
Output of 108642 with QT_LOGGING_RULES=qt.scenegraph.general.debug=true on affected system (6.71 KB, text/plain)
2017-11-08 14:25 UTC, Vova Mshanetskiy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sparhawk 2017-06-09 02:56:57 UTC
Setting the background to slideshow causes high CPU load.

* 80% for plasmashell
* 50% for kwin_x11
* 40% for Xorg -nolisten tcp -auth /var/run/sddm/{<random_string>} -background none -noreset -displayfd 18 vt1

The picture is set to change every 10 minutes. After changing the background to a static image, CPU usage drops to normal.

This bug is present in Plasma 5.10.1 but not 5.10.0.
Comment 1 sparhawk 2017-06-09 03:58:29 UTC
I've managed to reproduce it with a fairly minimal setup. The following is in ~/.config/plasma-org.kde.plasma.desktop-appletsrc

N.B. I can only reproduce this with two monitors, and with the colour picker plasmoid on one.

[Containments][182]
activityId=90a9313e-ad43-4d01-b35a-9b9094162ce1
formfactor=0
immutability=1
lastScreen=5
location=0
plugin=org.kde.desktopcontainment
wallpaperplugin=org.kde.slideshow

[Containments][182][Wallpaper][org.kde.slideshow][General]
FillMode=1
SlideInterval=600
SlidePaths=/home/sparhawk/HDD/Personal/Pictures/Wallpapers/Plasma_current
height=1080
width=1920

[Containments][7]
activityId=90a9313e-ad43-4d01-b35a-9b9094162ce1
formfactor=0
immutability=1
lastScreen=0
location=0
plugin=org.kde.desktopcontainment
wallpaperplugin=org.kde.slideshow

[Containments][7][Applets][92]
immutability=1
plugin=org.kde.plasma.colorpicker

[Containments][7][Wallpaper][org.kde.slideshow][General]
FillMode=1
SlideInterval=600
SlidePaths=/home/sparhawk/HDD/Personal/Pictures/Wallpapers/Plasma_current
height=1080
width=1920

[General]
immutability=2
Comment 2 sparhawk 2017-06-09 04:03:28 UTC
N.B. removing the colour picker plasmoid from my default setup is not sufficient to reduce CPU usage. However, using static images as the background *is* sufficient.

Further, using static images on the secondary screen reduces plasmashell CPU usage to ~10%. Changing both monitors reduces it to ~4%.
Comment 3 Chris Holland 2017-06-09 05:04:29 UTC
There hasn't been any changes to the image/slideshow wallpaper "plugin" since April.

https://github.com/KDE/plasma-workspace/commits/master/wallpapers/image



Slideshow will watch the directory twice for some reason.

https://github.com/KDE/plasma-workspace/blob/master/wallpapers/image/image.cpp#L139

Hmm, is your slideshow image on another drive? Is the partition NTFS or ...?
 Does selecting a slideshow on the same drive also have high CPU?


Hmmm, it seems KDirWatch did update 15 days ago, but I don't see how it would affect things.

https://github.com/KDE/kcoreaddons/commits/master/src/lib/io

Did Qt update too? What's your Qt version?
Comment 4 sparhawk 2017-06-09 05:18:16 UTC
> There hasn't been any changes to the image/slideshow wallpaper "plugin" since April.

As per comment 1 and comment 2, there might be something antagonistic with other plasmoids… so perhaps it's not just the slideshow "plugin" by itself.

> Hmm, is your slideshow image on another drive? Is the partition NTFS or ...?
> Does selecting a slideshow on the same drive also have high CPU?

I have an SDD and spindle HDD on my laptop. (Most of the) system is on the SDD and the wallpapers are on the HDD. It's all ext4. I tried changing the wallpaper directory to the SDD, but I still get the high CPU.

> Did Qt update too? What's your Qt version?

Yes, it did. qt5-base (5.8.0-12 -> 5.9.0-2)

In fact the following packages all updated to 5.9.0-1.

qt5-base qt5-xmlpatterns qt5-declarative qt5-multimedia qt5-speech qt5-x11extras qt5-script qt5-svg qt5-webchannel qt5-location qt5-webengine qt5-quickcontrols qt5-sensors qt5-webkit qt5-tools qt5-graphicaleffects qt5-imageformats qt5-quickcontrols2

I can test reverting these if you think it's helpful.
Comment 5 Chris Holland 2017-06-09 05:22:47 UTC
If it's not too much trouble.
Comment 6 sparhawk 2017-06-09 05:34:31 UTC
Huh… good instincts! Yep, that fixes it. I reverted the following packages and that fixed it.

qt5-base              5.8.0-12
qt5-declarative       5.8.0-2
qt5-graphicaleffects  5.8.0-1
qt5-imageformats      5.8.0-2
qt5-location          5.8.0-1
qt5-multimedia        5.8.0-1
qt5-quickcontrols     5.8.0-1
qt5-quickcontrols2    5.8.0-1
qt5-script            5.8.0-1
qt5-sensors           5.8.0-1
qt5-speech            5.8.0-2
qt5-svg               5.8.0-1
qt5-tools             5.8.0-1
qt5-webchannel        5.8.0-1
qt5-webengine         5.8.0-9
qt5-webkit            5.8.0-3
qt5-x11extras         5.8.0-1
qt5-xmlpatterns       5.8.0-1

So how can we tell if this a bug in qt5, or the way in which plasma interacts with it?
Comment 7 Lars Altenhain 2017-06-09 10:28:23 UTC
I can reproduce this also an openSUSE Leap 42.2 with QT5.9 and Plasma 5.10.1 on a single monitor setup. Setting the background to slideshow shows increasing CPU load up to 100% for plasmashell and 50% for Xorg. Additionally the icons on the desktop are redrawn  every few seconds and start flickering.

The difference in my case is, that the CPU load does not drop to normal when changing back the background to a static image. I have to kill and restart plasmashell.
Comment 8 Chris Holland 2017-06-09 12:34:32 UTC
Does editing
/usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml

and setting "cache: true" on both Image at the bottom of the file, then restarting plasma change anything?

killall plasmashell; kstart5 plasmashell
Comment 9 Lars Altenhain 2017-06-09 13:06:00 UTC
I have made the change to the main.qml file, restarted plasmashell, activated the slightshow again and the CPU load stays low.
Comment 10 sparhawk 2017-06-09 13:18:14 UTC
(In reply to Lars Altenhain from comment #7)
> The difference in my case is, that the CPU load does not drop to normal when
> changing back the background to a static image. I have to kill and restart
> plasmashell.

Ah yes, sorry, I should have mentioned. I also have been killing and restarting plasmashell before retesting.

(In reply to Chris Holland from comment #8)
> Does editing
> /usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml
> 
> and setting "cache: true" on both Image at the bottom of the file, then
> restarting plasma change anything?
> 
> killall plasmashell; kstart5 plasmashell

Not for me. I made the changes, and CPU usage stays high.
Comment 11 sparhawk 2017-06-09 13:19:28 UTC
Just to be explicit, these were the changes I made.

--- main.qml.orig	2017-06-09 23:12:07.378217321 +1000
+++ main.qml	2017-06-09 23:14:15.277940978 +1000
@@ -213,7 +213,7 @@
         id: imageA
         anchors.fill: parent
         asynchronous: true
-        cache: false
+        cache: true
         fillMode: wallpaper.configuration.FillMode
         autoTransform: true //new API in Qt 5.5, do not backport into Plasma 5.4.
     }
@@ -221,7 +221,7 @@
         id: imageB
         anchors.fill: parent
         asynchronous: true
-        cache: false
+        cache: true
         fillMode: wallpaper.configuration.FillMode
         autoTransform: true //new API in Qt 5.5, do not backport into Plasma 5.4.
     }
Comment 12 Vadym Krevs 2017-06-09 23:14:22 UTC
(In reply to sparhawk from comment #10)
> (In reply to Lars Altenhain from comment #7)
> > The difference in my case is, that the CPU load does not drop to normal when
> > changing back the background to a static image. I have to kill and restart
> > plasmashell.
> 
> Ah yes, sorry, I should have mentioned. I also have been killing and
> restarting plasmashell before retesting.
> 
> (In reply to Chris Holland from comment #8)
> > Does editing
> > /usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml
> > 
> > and setting "cache: true" on both Image at the bottom of the file, then
> > restarting plasma change anything?
> > 
> > killall plasmashell; kstart5 plasmashell
> 
> Not for me. I made the changes, and CPU usage stays high.

Same here.
Comment 13 Lars Altenhain 2017-06-12 11:26:05 UTC
(In reply to Lars Altenhain from comment #9)
> I have made the change to the main.qml file, restarted plasmashell,
> activated the slightshow again and the CPU load stays low.

It seems I spoke to early. After activating the slideshow also on the other activities the CPU load goes up again.

I did some more tests:
If I have the slideshow active on more than one activity the CPU load goes up every time, even after I kill/restart plasmashell. With the slideshow active only on one activity the CPU load goes up after activating the slideshow, but there is a 50/50 chance that the load stays low after killing/restarting plasmashell.
Comment 14 Chris Holland 2017-06-12 12:47:19 UTC
What's your slideshow interval?

Maybe if you wait for the image to change? Does the cpu spike when the image changes? Maybe it doesn't spike until then (first image loads fine with low cpu usage). That's one reason I can think of that it would be a 50/50 chance.

The other is that Qt's image cache is full one time, and not the next. That actually seems more likely... hmmm, though it's not something I'd be able to debug. I need to read up on how Qt caches images.
Comment 15 Lars Altenhain 2017-06-12 13:48:55 UTC
(In reply to Chris Holland from comment #14)
> What's your slideshow interval?

I have set the interval to 5 minutes.
> 
> Maybe if you wait for the image to change? Does the cpu spike when the image
> changes? Maybe it doesn't spike until then (first image loads fine with low
> cpu usage). That's one reason I can think of that it would be a 50/50 chance.
> 
> The other is that Qt's image cache is full one time, and not the next. That
> actually seems more likely... hmmm, though it's not something I'd be able to
> debug. I need to read up on how Qt caches images.

If the CPU load stayed low after restarting plasmashell it also didn't go up when the next image change occurred. In that case I only see a short spike every time the image changes.

Another thing I found in the meantime:
I have logged into a second session using a newly created test user and I can't reproduce the problem with this user at all, even with the original main.qml file. I tried to setup the desktop in the same way I have on my normal user account: Creating 3 activities and activate the slideshow on all of them using the same folder for the images I have used on my normal user account. 

I also see that the CPU load of plasmashell even with static background images is slighlty higher on my normal user account. Here I have always ~2% for plasmashell. On the test user plasmashell stays below 1% even with the slideshow active and I only see short spikes when the background image changes or I change the to another activity.

My normal user account has config files which are carried over from KDE4.
Comment 16 Lars Altenhain 2017-06-12 14:43:21 UTC
(In reply to Lars Altenhain from comment #15)

> I also see that the CPU load of plasmashell even with static background
> images is slighlty higher on my normal user account. Here I have always ~2%
> for plasmashell. On the test user plasmashell stays below 1% even with the
> slideshow active and I only see short spikes when the background image
> changes or I change the to another activity.
> 
This has nothing to do with the background image / slideshow. I had slightly different settings on the cpu load plasmoid for both users. If I use the same settings also for the test user I see the 2% for plasmashell on both users.

I still can't reproduce the problem with my test user. I tried changing between static image and slideshow several times now and the CPU load stays low, no need to set the cache mode in the main.qml file to true or restarting plasmashell. There must be something in the configuration files of my normal user that triggers the high CPU load behaviour.
Comment 17 sparhawk 2017-06-13 02:07:44 UTC
(In reply to Lars Altenhain from comment #13)
> If I have the slideshow active on more than one activity the CPU load goes up every time
I wonder if that's similar to my situation, when I only see high CPU with slideshow on dual monitors. (I don't use activities.)

(In reply to Chris Holland from comment #14)
> What's your slideshow interval?
> Does the cpu spike when the image changes?
FWIW mine is ten minutes, and it's a constant high CPU, not a spike.

Chris, did you manage to reproduce this bug with my settings file from comment #11? Otherwise I can try installing it in a new account and see if it's due to conflating issues, similar to Lars's findings.
Comment 18 Paul 2017-06-16 17:36:32 UTC
I've just updated an openSUSE Tumbleweed system, this included Qt 5.71 -> 5.9

I'm seeing the same substantial increase in CPU utilisation. I posted details to the openSUSE forum (before finding this bug report) https://forums.opensuse.org/showthread.php/525431-plasmashell-kwin_X11-substantial-increase-in-CPU-utilisation-after-20170615-snapshot 

I'll try the fix proposed in comment #8 but won't be able to until tomorrow.
Comment 19 Paul 2017-06-17 12:45:56 UTC
(In reply to Paul from comment #18)
> 
> I'll try the fix proposed in comment #8 but won't be able to until tomorrow.
>

Having set "cache:true" and restarted plasmashell the CPU utilisation returns to "normal".

Setting the slideshow interval to 30 secs and observing CPU utilisation over several image changes, there is a spike of 70%+ as the image changes which then drops to normal afterwards.  I will set my normal interval (1hr) and see how it behaves over the next few days.

This is a single screen setup and I don't use activities.

Plasma 5.10.1
KDE frameworks 5.34.0
Qt 5.9.0
Comment 20 Paul 2017-06-17 14:03:53 UTC
(In reply to Paul from comment #19)
> 
> I will set my normal interval (1hr) and
> see how it behaves over the next few days.
> 

Didn't need a few days.  After using the machine normally, at the next image change an hour later the CPU utilisation went up to 70%+ and remained there.
Comment 21 Cristiano Guadagnino 2017-06-20 07:51:00 UTC
Had the same problem here (openSUSE Tumbleweed, plasmashell v5.10.2, two monitors).
Changed background to a static image on both monitors and restarted plasmashell, now CPU usage is back to normal.
Comment 22 Chris Holland 2017-06-20 22:58:51 UTC
So Neon now has Qt 5.9, and I can reproduce it with Plasma 5.10.2. It only started after yesterdays update to qt 5.9 from qt 5.7.

Anyhow. Testing cache:true didn't fix it. However, setting asynchronous:true to asynchronous:false DID fix it.
Comment 23 Chris Holland 2017-06-21 00:11:09 UTC
So... I tried reproducing it with qmlscene, but couldn't. I tried `qmlscene plasmaSlideshowText.qml`
https://gist.github.com/Zren/8515913f9de052e4f219700fb2c0525a

Maybe it's probably still using qt 5.7 somehow? I tried adding that to a widget and it reproduced the results when run in *plasmashell*. Plasmoidviewer didn't reproduce it.

* Test (async:true) https://streamable.com/ky66w
* Test (async:false) https://streamable.com/esppp


-----
Checking out qt's code. tl;dr: I found nothing, but I might as well attach the links.


Nothing in QQuickImage.cpp
https://github.com/qt/qtdeclarative/blob/dev/src/quick/items/qquickimage.cpp

But in it's base class
https://github.com/qt/qtdeclarative/blame/dev/src/quick/items/qquickimagebase.cpp#L237

QQuickPixmap::Options options;
options |= QQuickPixmap::Asynchronous;

is defined in:
https://github.com/qt/qtdeclarative/blob/cf059f045e5558231fe12607659fc67bd2259389/src/quick/util/qquickpixmapcache_p.h#L124


Note: Qt 5.7.1 was released December 14th, 2016
Note: Qt 5.8.0 was released Monday January 23rd, 2017

I'm not sure if arch's revison 12 5.8.0-12 uses patches later than that, but I'll use that as a starting window for checking commits.

https://github.com/qt/qtdeclarative/commits/dev/src/quick/util/qquickpixmapcache.cpp
https://github.com/qt/qtdeclarative/blame/dev/src/quick/util/qquickpixmapcache.cpp
Comment 24 Paul 2017-06-21 17:09:14 UTC
(In reply to Chris Holland from comment #22)
> So Neon now has Qt 5.9, and I can reproduce it with Plasma 5.10.2. It only
> started after yesterdays update to qt 5.9 from qt 5.7.
> 
> Anyhow. Testing cache:true didn't fix it. However, setting asynchronous:true
> to asynchronous:false DID fix it.

Not on this system I'm afraid.  Edited "/usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml" changing "asynchronous:true" to "asynchronous:false" and restarting plasmashell.

67% plasmashell
60% kwin_X11
39% X

Reverting back to a static image and restarting plasmashell

0.8% plasmashell
9% kwin_X11
5% X



Plasma 5.10.2
KDE frameworks 5.34.0
Qt 5.9.0
Comment 25 Thomas Demeter 2017-06-26 17:06:52 UTC
I can reproduce this issue on the latest KDE Neon. I have a ThinkPad X270 with an i5-7200U CPU/GPU.

But even on the older Qt, just enabling the slideshow put plasma around 5-10% CPU use. Now that I disabled it (the slideshow was one of the first thing I configured after the install), all CPU usage from plasma disappeared.
Comment 26 sparhawk 2017-06-29 01:30:35 UTC
(In reply to Chris Holland from comment #22)
> However, setting asynchronous:true to asynchronous:false DID fix it.

Sorry for the delay. I've been having other, unrelated issues… anyway, making this change as below did *not* fix it for me either.

--- /usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml.orig	2017-06-29 11:25:42.729305733 +1000
+++ /usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml	2017-06-29 11:26:50.959618628 +1000
@@ -212,7 +212,7 @@
     Image {
         id: imageA
         anchors.fill: parent
-        asynchronous: true
+        asynchronous: false
         cache: false
         fillMode: wallpaper.configuration.FillMode
         autoTransform: true //new API in Qt 5.5, do not backport into Plasma 5.4.
@@ -220,7 +220,7 @@
     Image {
         id: imageB
         anchors.fill: parent
-        asynchronous: true
+        asynchronous: false
         cache: false
         fillMode: wallpaper.configuration.FillMode
         autoTransform: true //new API in Qt 5.5, do not backport into Plasma 5.4.
Comment 27 David Edmundson 2017-06-30 12:28:18 UTC
Given someone says it's a change in Qt can you try list what versions of Qt have and don't have this issue.
Comment 28 sparhawk 2017-06-30 12:30:13 UTC
David Edmundson, see comment 4 and comment 6.
Comment 29 Koen 2017-07-03 10:09:14 UTC
I cannot get rid of the high cpu usage in kdeplasmashell. Whatever screen option I choose. I tried the default breeze background, a black color. It's at 15% after an hour. It's like my laptop is going to take out of to space.
Comment 30 Koen 2017-07-03 10:12:11 UTC
And the qt version seems to be 5.9.0-1.1 (opensuse tumbleweed latest version)
Comment 31 sparhawk 2017-07-03 11:50:20 UTC
I also think that even without slideshow, it's slowly getting worse with each update, although it's nothing like the 80/50/40% that I originally reported (with slideshow). 15% is pretty good IMO! I think I used to get ~5–10% *before* this bug started! Now I often get ~40% without slideshow, but I can usually kill plasma and it restarts.
Comment 32 Koen 2017-07-04 06:01:04 UTC
cntrl-esc -> system activity shows 15%
htop shows around 120%

... for plasmashell
pretty much a few minutes after boot
Comment 33 Sebastian 2017-07-04 06:52:49 UTC
I can confirm this behaviour, on actual KDE Neon and Archlinux with KDE.

And the reason is definitly the slideshow, with static image the CPUload drops to 2%, changing to slideshow rises to 120%, and back...

I tries most hints in this thread, but none of them helps.
Comment 34 sparhawk 2017-07-05 01:09:01 UTC
FWIW I just upgraded to qt5 5.9.1 and this bug is still present. So to summarise, it's present for me in qt5 5.9.1 and 5.9.0, but *not* 5.8.0.
Comment 35 Chris Holland 2017-07-05 17:32:50 UTC
Running the following with slideshow and image shows that something is making the scenegraph "dirty".

killall plasmashell; QT_LOGGING_RULES="*.debug=true" plasmashell


With slideshow, we get this spammed nonstop.

    qt.quick.dirty: QQuickWindowPrivate::updateDirtyNodes():
    qt.scenegraph.time.renderer: time in renderer: total=15ms, preprocess=0, updates=0, binding=0, rendering=14
    qt.scenegraph.time.renderloop: Frame rendered with 'basic' renderloop in 16ms, polish=0, sync=0, render=15, swap=0, frameDelta=16
    qt.quick.dirty: QQuickWindowPrivate::updateDirtyNodes():
    qt.scenegraph.time.renderer: time in renderer: total=15ms, preprocess=0, updates=0, binding=0, rendering=15
    qt.scenegraph.time.renderloop: Frame rendered with 'basic' renderloop in 16ms, polish=0, sync=0, render=15, swap=0, frameDelta=17
    qt.quick.dirty: QQuickWindowPrivate::updateDirtyNodes():

https://gist.github.com/Zren/c52c4bceb0aa5390dea137cc031745c2#file-gistfile1-txt-L546

Where as with image it's not spammed.
Comment 36 TOM Harrison 2017-07-06 03:39:38 UTC
I could also confirm this.
this issue is more visible if you are using intel graphic card (aka i915 driver)
I found is I switch to slideshow and restart plasmashell. plasmashell will always using lots of cpu. As time pass, it will using more CPU. In my case, It will use almost 100% in htop, meaning almost one cpu to do that.
If I switch to static image and restart plasmashell, plasmashell no longer constant using lots of cpu, drop to 0%.

reproduce.
1. switch to slideshow.
2. add more than one directory with many image, and press OK
3. restart plasmashell.
4. you will see plasmashell eating your cpu as time pass.
Comment 37 sparhawk 2017-07-06 04:07:24 UTC
(In reply to TOM Harrison from comment #36)
> 2. add more than one directory with many image, and press OK

FWIW I see this bug even with just a single directory with a single image in it. (I curl a daily image into this directory.)
Comment 38 David Edmundson 2017-07-06 08:42:55 UTC
Can someone get a partial callgrind log please of after it has loaded and when it's doing it's high CPU thing.

See
https://stackoverflow.com/questions/2400025/how-use-callgrind-to-profiling-only-a-certain-period-of-program-execution#3299472

Make sure you have debug symbols for plasma-workspace, frameworks and Qt.
Comment 39 David Edmundson 2017-07-10 10:13:04 UTC
Can someone add the following line of debug. 

+            Component.onCompleted: console.log("DAVE: ANIMATION DURATION = ", fadeOtherAnimator.duration);


after the 

         ParallelAnimation { on line 175

Then show me the debug output of running plasmashell

(alternatively just change line 191 to be a hardcoded value and tell me if it goes away)
Comment 40 Paul 2017-07-10 12:17:23 UTC

Added debug line:

Component.onCompleted: console.log("DAVE: ANIMATION DURATION = ", fadeOtherAnimator.duration);

to "/usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml"


With slideshow set restarted plasmashell allow one image change to take place (debug text is NOT output):

=========
slideshow
=========

paul@Orion-Tumble:~$ kquitapp5 plasmashell && kstart plasmashell
kstart(1843) main: Omitting both --window and --windowclass arguments is not recommended 
paul@Orion-Tumble:~$ org.kde.kcoreaddons: Expected JSON property "X-Plasma-ContainmentCategories" to be a string list. Treating it as a list with a single entry: "panel" org.opensuse.desktop.defaultPanel
WARNING: Cannot find style "org.kde.desktop" - fallback: "/usr/lib64/qt5/qml/QtQuick/Controls/Styles/Desktop"
No file found for ".xml" , even though update-mime-info said it would exist.
Either it was just removed, or the directory doesn't have executable permission... ("/home/paul/.local/share/mime", "/usr/share/mime")
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No file found for ".xml" , even though update-mime-info said it would exist.
Either it was just removed, or the directory doesn't have executable permission... ("/home/paul/.local/share/mime", "/usr/share/mime")
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
Trying to use rootObject before initialization is completed, whilst using setInitializationDelayed. Forcing completion
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:78:27: Unable to assign [undefined] to QStringList
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:37: TypeError: Cannot read property 'DateTime' of undefined
Loading Calendar plugin HolidaysEventsPlugin(0x560c551dfd50)
Both point size and pixel size set. Using pixel size.
Both point size and pixel size set. Using pixel size.
Both point size and pixel size set. Using pixel size.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:362: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:363: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:364: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:365: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:362: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:363: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:364: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:365: TypeError: Cannot read property 'padding' of null
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PulseAudio.qml:22:1: module "org.kde.plasma.private.volume" is not installed
Notifications service registered
libkcups: Create-Printer-Subscriptions last error: 0 successful-ok
libkcups: Get-Jobs last error: 0 successful-ok
libkcups: Get-Jobs last error: 0 successful-ok
Plasma Shell startup completed
libkcups: 0
libkcups: 0                                                                                                                                                                                                                                                                                                                 
Path traversal attempt detected: "/usr/share/kservices5/plasma-applet-org.kde.plasma.networkmanagement.desktop" is not inside "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/"                                                                                                                               
Path traversal attempt detected: "/usr/share/kservices5/plasma-applet-org.kde.plasma.networkmanagement.desktop" is not inside "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/"                                                                                                                               
Path traversal attempt detected: "/usr/share/kservices5/plasma-applet-org.kde.plasma.networkmanagement.desktop" is not inside "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/"                                                                                                                               
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "AllDevices"                                                                                                                                                                                        
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "Capabilities"                                                                                                                                                                                      
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "Devices"                                                                                                                                                                                           
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "GlobalDnsConfiguration"                                                                                                                                                                            
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "S390Subchannels"                                                                                                                                                                        
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
DBusMenu disabled for this application                                                                                                                                                                                                                                                                                      
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"                                                                                                                                                                                                                                   
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"                                                                                                                                                                                                                                   
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                            


Reverting to static image and restarting plasmashell:  (debug text IS output)

============
static image
============

paul@Orion-Tumble:~$ kquitapp5 plasmashell && kstart plasmashell
kstart(1794) main: Omitting both --window and --windowclass arguments is not recommended 
paul@Orion-Tumble:~$ org.kde.kcoreaddons: Expected JSON property "X-Plasma-ContainmentCategories" to be a string list. Treating it as a list with a single entry: "panel" org.opensuse.desktop.defaultPanel
WARNING: Cannot find style "org.kde.desktop" - fallback: "/usr/lib64/qt5/qml/QtQuick/Controls/Styles/Desktop"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
No metadata file in the package, expected it at: "/home/Common-Public/Wallpapers-Cyclic/"
qml: DAVE: ANIMATION DURATION =  1000
Trying to use rootObject before initialization is completed, whilst using setInitializationDelayed. Forcing completion
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:78:27: Unable to assign [undefined] to QStringList
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:37: TypeError: Cannot read property 'DateTime' of undefined
Loading Calendar plugin HolidaysEventsPlugin(0x563a4525f650)
Both point size and pixel size set. Using pixel size.
Both point size and pixel size set. Using pixel size.
Both point size and pixel size set. Using pixel size.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:362: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:363: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:364: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:365: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:362: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:363: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:364: TypeError: Cannot read property 'padding' of null
file:///usr/lib64/qt5/qml/QtQuick/Controls/ScrollView.qml:365: TypeError: Cannot read property 'padding' of null
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PulseAudio.qml:22:1: module "org.kde.plasma.private.volume" is not installed
Notifications service registered
libkcups: Create-Printer-Subscriptions last error: 0 successful-ok
libkcups: Get-Jobs last error: 0 successful-ok
libkcups: Get-Jobs last error: 0 successful-ok
Plasma Shell startup completed
libkcups: 0
libkcups: 0
Path traversal attempt detected: "/usr/share/kservices5/plasma-applet-org.kde.plasma.networkmanagement.desktop" is not inside "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/"
Path traversal attempt detected: "/usr/share/kservices5/plasma-applet-org.kde.plasma.networkmanagement.desktop" is not inside "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/"
Path traversal attempt detected: "/usr/share/kservices5/plasma-applet-org.kde.plasma.networkmanagement.desktop" is not inside "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/"
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "AllDevices"
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "Capabilities"
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "Devices"
networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) Unhandled property "GlobalDnsConfiguration"
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "S390Subchannels"                                                                                                                                                                        
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "LldpNeighbors"                                                                                                                                                                          
networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Real"                                                                                                                                                                                   
DBusMenu disabled for this application  



(On a side note:

I have:

[Units]
longDuration=5

in ~/.config/plasmarc

to effectively disable plasma animations.)



Removing your debug line and hardcoding as follows:

-  duration: units.longDuration && wallpaper.configuration.TransitionAnimationDuration

+  duration: 1000

and restarting plasmashell with slideshow does NOT reduce the CPU utilisation to a 'normal' level.
Comment 41 David Edmundson 2017-07-13 18:58:49 UTC
*** Bug 382288 has been marked as a duplicate of this bug. ***
Comment 42 Mircea Kitsune 2017-07-13 19:18:10 UTC
Created attachment 106594 [details]
Screenshot of blank wallpaper / media frame

I have the same problem. As I mentioned in my report, it happens with both the slideshow wallpaper and a slideshow media frame widget: Both cause a memory leak (seemingly disk cache)... whereas after a few hours, they both become black, and clicking certain buttons on the desktop cause it to crash and restart. This seems to have been introduced by upgrading from libQt5Core5 5.9.0 to 5.9.1.

I'll attach a screenshot of my desktop as it becomes broken; It shows both the Media Frame widget and slideshow wallpaper being replaced by a black color, whereas normally they should contain images... it's at this point that clicking on things causes Plasma to die. Edits include me blurring the contents of a plasmoid, and adding the red text and arrows to for better indication.
Comment 43 Christoph Feck 2017-07-17 18:15:55 UTC
*** Bug 382316 has been marked as a duplicate of this bug. ***
Comment 44 Christoph Feck 2017-07-17 18:16:22 UTC
*** Bug 382413 has been marked as a duplicate of this bug. ***
Comment 45 gilaldpellaeon 2017-07-17 20:08:10 UTC
Created attachment 106683 [details]
Massif snapshots of the plasmashell process.

Hi guys.

Since the original bug I had posted to has been marked as a duplicate of this one, I'm copying my message as well. Hopefully it could help to analyze the problem. And to accept the fact that the problem exists.

I happen to have a memory leaking problem while having wallpaper set to a slideshow mode.
Actually I've made some measurements while changing wallpapers manually (and then resting for a while) with the Massif tool (valgrind).

Could somebody from the dev team please have a look? I've tried to do a research but I know too little about how Qt handles graphics so it's not that obvious for me. Having said that, it's still pretty obvious that memory region passed to nvidia libgl (in my case) is never freed.

Thanks.
Comment 46 mcgyver 2017-07-18 14:21:10 UTC
As the problem I am experiencing (bug 382288) has been marked duplicate of this bug, I am reporting here my experience. Please let me know if I can contribute with more info:

 - Arch Linux Desktop with 4 screens all set with a slideshow background
 - Plasmashell memory occupation grows continuously
 - Selecting a static background image seems to solve the problem
 - Changing the background desktop image increases Plasmashell memory occupation
 - Downgrading Qt packages to these version is a workaround:
qt5-base 5.9.0-2
qt5-connectivity 5.9.0-1
qt5-declarative 5.9.0-1
qt5-graphicaleffects 5.9.0-1
qt5-location 5.9.0-1
qt5-multimedia 5.9.0-1
qt5-quickcontrols 5.9.0-1
qt5-quickcontrols2 5.9.0-1
qt5-script 5.9.0-1
qt5-scxml 5.9.0-1
qt5-sensors 5.9.0-1
qt5-serialport 5.9.0-1
qt5-speech 5.9.0-1
qt5-svg 5.9.0-1
qt5-tools 5.9.0-1
qt5-webchannel 5.9.0-1
qt5-webengine 5.9.0-2
qt5-webkit 5.9.0-1
qt5-websockets 5.9.0-1
qt5-x11extras 5.9.0-1
qt5-xmlpatterns 5.9.0-1
Comment 47 Paul 2017-07-18 15:12:23 UTC
So, ...

Is the memory leak that is now being reported in posts #42 onwards, and introduced by the Qt update to V5.9.1 ...

also related to the high CPU usage of plasmashell and kwin_x11, introduced by the update of Qt to V5.9.0. Which was the original subject of this bug report upto post #42.
Comment 48 mcgyver 2017-07-18 17:02:50 UTC
As far as I can see, if I revert back to old Qt libraries the problem disappears.

On my side, all these memory problems started with a Qt update.
Comment 49 mcgyver 2017-07-18 17:03:49 UTC
And yes, the update is to Qt 5.9.1
Comment 50 David Edmundson 2017-07-18 17:39:37 UTC
Thanks for the massif trace.

It shows high usage of both QImage and in OpenGL, which implies it's our QSGTexture objects not being deleted; which would put the bug in Qt or us not underlying libs.

It would be very interesting to see, if you had a slideshow of two images going back and forth if the resources are static or continuiing out of control.

Also if anyone can build with latest of the Qt 5.9 branch that would be useful. 
I don't see the issue here, which could mean it's fixed, at which point we don't need to do anything
Comment 51 David Edmundson 2017-07-18 17:42:02 UTC
eeb320bbd8763f3e72f79369cc3908e999a0da3c is potentially relevant.
Comment 52 mcgyver 2017-07-18 20:57:45 UTC
I have tried by hand loading two images alternatively and the memory was increasing every time, as the memory was allocated from scratch each time for the loaded image.
Comment 53 sparhawk 2017-07-18 23:46:06 UTC
@mcgyver Is it definitely qt 5.9.1 where the bug appeared for you, and 5.9.0 was okay? As per comment #4 and comment #6, the bug appeared for me in 5.9.0, and 5.8.0 was fine. I'm also on Arch.
Comment 54 Mircea Kitsune 2017-07-18 23:54:29 UTC
I can also confirm the bug was introduced when upgrading from libQt5Core5 5.9.0 to 5.9.1. There were no other updates to system or KDE components in this snapshot, so I don't doubt that's what caused it for me.
Comment 55 mcgyver 2017-07-19 07:27:51 UTC
Yes, I am pretty sure it is related to Qt 5.9.1: if I upgrade the packages to the latest version, I have the problem; if I downgrade as per comment #46 the problem disappears
Comment 56 mcgyver 2017-07-19 08:49:48 UTC
However, this morning I just realised that the slideshow is not the entire problem: plasmashell memory occupation bloated even though I have stopped the slideshow.
It happens much more slowly, but still in 1 day plasmashell memory occupation went up to 2GB.
Comment 57 Mircea Kitsune 2017-07-19 11:14:10 UTC
(In reply to mcgyver from comment #56)

This would explain why, some time after Plasma has caused my system to reach 10GB of used memory, the wallpaper and media frame become black then the desktop crashes and restarts if I click on some things. I didn't test this theory, but that behavior does feel as if plasmashell is running out of allocated memory (thank goodness or my computer would run out of RAM).
Comment 58 David Edmundson 2017-07-19 20:15:33 UTC
*** Bug 381471 has been marked as a duplicate of this bug. ***
Comment 59 David Edmundson 2017-07-19 20:16:42 UTC
Can someone try to rebuild Qt without the commit in #50 please
Comment 60 Antonio Rojas 2017-07-19 20:38:49 UTC
(In reply to David Edmundson from comment #59)
> Can someone try to rebuild Qt without the commit in #50 please

Archlinux users can test the build from http://pkgbuild.com/~arojas/qt5-declarative-5.9.1-3.1-x86_64.pkg.tar.xz
Comment 61 gilaldpellaeon 2017-07-20 09:59:02 UTC
Created attachment 106755 [details]
Massif snapshot w/o eeb320bbd (many pics)

In this analysis I've been rapidly changing wallpapers in a random order.
Comment 62 gilaldpellaeon 2017-07-20 10:00:06 UTC
Created attachment 106756 [details]
Massif snapshot w/o eeb320bbd (2 pics)

In this analysis I've been rapidly swapping only two wallpapers.
Comment 63 gilaldpellaeon 2017-07-20 10:03:14 UTC
So it seems like the commit eeb320bbd has indeed introduced this memory leakage. We'll see how it performs in a long term.
Comment 64 David Edmundson 2017-07-20 14:13:43 UTC
Thanks guys.

From what I understand, this means if one runs with:

QSG_RENDER_LOOP=basic plasmashell 
or
QSG_RENDER_LOOP=threaded plasmashell 

We'll see different results. Can someone with the bug test that please?
Comment 65 David Edmundson 2017-07-20 14:17:49 UTC
Also can I have output of

QT_LOGGING_RULES=qt.scenegraph.renderloop.debug=true plasmashell

from someone with the bug
Comment 66 TOM Harrison 2017-07-20 15:06:25 UTC
Created attachment 106764 [details]
log output with QT_LOGGING_RULES=qt.scenegraph.renderloop.debug=true
Comment 67 gilaldpellaeon 2017-07-20 15:11:16 UTC
(In reply to David Edmundson from comment #64)
> Thanks guys.
> 
> From what I understand, this means if one runs with:
> 
> QSG_RENDER_LOOP=basic plasmashell 
> or
> QSG_RENDER_LOOP=threaded plasmashell 
> 
> We'll see different results. Can someone with the bug test that please?

No problem, will do.
Comment 68 gilaldpellaeon 2017-07-20 15:55:39 UTC
Created attachment 106767 [details]
Massif analysis, QSG_RENDER_LOOP=basic

Plasmashell run in a QSG_RENDER_LOOP=basic mode for exactly 10 minutes with wallpapers being changed every 5 seconds.
Comment 69 gilaldpellaeon 2017-07-20 15:56:19 UTC
Created attachment 106768 [details]
Massif analysis, QSG_RENDER_LOOP=threaded

Plasmashell run in a QSG_RENDER_LOOP=threaded mode for exactly 10 minutes with wallpapers being changed every 5 seconds.
Comment 70 David Edmundson 2017-07-21 12:53:59 UTC
To summarise:

It's clear QSGContext::endSync() isn't being called.

It changed when it went from being done once to being up to the rendering engine to do it. This does it afer *all* windows have synced but not one.

The change in QSGRenderThreadedLoop.cpp isn't relevant, that's just on the grab, it'll be the change in  QSGRenderLoop.cpp

I'm gonna need someone who can reliably reproduce this to throw some debug in there and get a list of m_windows after line 309 along with window and also to see if we hit the returns on line 394 and 400.
Comment 71 gilaldpellaeon 2017-07-21 13:02:37 UTC
(In reply to David Edmundson from comment #70)
> To summarise:
> 
> It's clear QSGContext::endSync() isn't being called.
> 
> It changed when it went from being done once to being up to the rendering
> engine to do it. This does it afer *all* windows have synced but not one.
> 
> The change in QSGRenderThreadedLoop.cpp isn't relevant, that's just on the
> grab, it'll be the change in  QSGRenderLoop.cpp
> 
> I'm gonna need someone who can reliably reproduce this to throw some debug
> in there and get a list of m_windows after line 309 along with window and
> also to see if we hit the returns on line 394 and 400.

Please count me in.
Comment 72 Alan Evans 2017-07-22 14:48:22 UTC
if it's of any help here's progressive screenshots of ksysguard over about a 40 minute period
No slideshow on the wallpaper, but I did have a media frame plasmoid with a slideshow
Have now disabled, and touch wood, all seems well

https://www.dropbox.com/s/13zhke8f85f1gwp/ksysguard_plasmashell_issue.zip?dl=0
Comment 73 TOM Harrison 2017-07-22 15:04:41 UTC
(In reply to Alan Evans from comment #72)
> if it's of any help here's progressive screenshots of ksysguard over about a
> 40 minute period
> No slideshow on the wallpaper, but I did have a media frame plasmoid with a
> slideshow
> Have now disabled, and touch wood, all seems well
> 
> https://www.dropbox.com/s/13zhke8f85f1gwp/ksysguard_plasmashell_issue.
> zip?dl=0

comment #60 has a build version that fix the memory leak issue.

I am now using that built with slide show for about two days. no leak what so ever.
but still waiting cpu usage issue to be fix.
Comment 74 Alan Evans 2017-07-22 15:13:21 UTC
(In reply to TOM Harrison from comment #73)
> (In reply to Alan Evans from comment #72)
> > if it's of any help here's progressive screenshots of ksysguard over about a
> > 40 minute period
> > No slideshow on the wallpaper, but I did have a media frame plasmoid with a
> > slideshow
> > Have now disabled, and touch wood, all seems well
> > 
> > https://www.dropbox.com/s/13zhke8f85f1gwp/ksysguard_plasmashell_issue.
> > zip?dl=0
> 
> comment #60 has a build version that fix the memory leak issue.
> 
> I am now using that built with slide show for about two days. no leak what
> so ever.
> but still waiting cpu usage issue to be fix.

That's for Arch users yes?
I'm on KDE Neon 16.0.4 User
Happy to leave the media frame disabled for now till the fix makes it's way into the repo if that's the best approach for me to take

Glad it's not just me anyhow
Comment 75 TOM Harrison 2017-07-23 01:47:55 UTC
(In reply to Alan Evans from comment #74)
> (In reply to TOM Harrison from comment #73)
> > (In reply to Alan Evans from comment #72)
> > > if it's of any help here's progressive screenshots of ksysguard over about a
> > > 40 minute period
> > > No slideshow on the wallpaper, but I did have a media frame plasmoid with a
> > > slideshow
> > > Have now disabled, and touch wood, all seems well
> > > 
> > > https://www.dropbox.com/s/13zhke8f85f1gwp/ksysguard_plasmashell_issue.
> > > zip?dl=0
> > 
> > comment #60 has a build version that fix the memory leak issue.
> > 
> > I am now using that built with slide show for about two days. no leak what
> > so ever.
> > but still waiting cpu usage issue to be fix.
> 
> That's for Arch users yes?
> I'm on KDE Neon 16.0.4 User
> Happy to leave the media frame disabled for now till the fix makes it's way
> into the repo if that's the best approach for me to take
> 
> Glad it's not just me anyhow

Yes, I transform that file to the package of ubuntu 16.04.
Comment 76 David Edmundson 2017-07-23 13:05:33 UTC
*** Bug 382602 has been marked as a duplicate of this bug. ***
Comment 77 Thomas Baag 2017-07-23 15:23:15 UTC
Comment 60 fixed the memory leak problem I described in bug 382602.
Comment 78 David Edmundson 2017-07-23 15:44:47 UTC
Created attachment 106799 [details]
Add debug in QtDeclarative QSGGuiThreadRenderLoop

Can someone run with this on QtDeclarative and attach the output please.

It won't fix anything, it just adds debug.
It only changes one of the render loops, but I think the relevant one.
Comment 79 Thomas Baag 2017-07-23 16:00:39 UTC
As this bug report made me aware of high (single thread) CPU usage of plasmashell I now can confirm this part of the bug. CPU usage is substantially higher with desktop slideshow enabled (~30%) than normal (1%-5%) when this bug happens.

It's harder to trigger than the memory leak bug. I had to have both screens set to slideshow. Setting picture to change every second helps a lot with triggering it. Still looks like some race condition.

With help of GALLIUM_HUD I found redraws go up a lot when the bug strikes. Climbing up to 330 redraws per second as shown here http://imgur.com/a/Y45SQ.
Comment 80 Thomas Baag 2017-07-23 17:24:14 UTC
Created attachment 106803 [details]
plasmashell output with qt5-declarative 5.9.1-3 patched with 106799
Comment 81 David Edmundson 2017-07-24 11:19:16 UTC
Thanks everyone. 
I've forwarded all this information as https://bugreports.qt.io/browse/QTBUG-62117
Comment 82 TOM Harrison 2017-07-24 11:35:58 UTC
(In reply to David Edmundson from comment #81)
> Thanks everyone. 
> I've forwarded all this information as
> https://bugreports.qt.io/browse/QTBUG-62117

how about the cpu usage ?
Comment 83 Mircea Kitsune 2017-07-24 12:30:46 UTC
(In reply to TOM Harrison from comment #82)

I'm not getting any excessive CPU usage. I have both a slideshow wallpaper and slideshow media frame, the first pointing to a directory 100 images big (15 minute timer) and the later to a folder 60000 images large (30 second timer). I wonder whether this might be a different bug altogether.
Comment 84 TOM Harrison 2017-07-24 12:43:50 UTC
(In reply to Mircea Kitsune from comment #83)
> (In reply to TOM Harrison from comment #82)
> 
> I'm not getting any excessive CPU usage. I have both a slideshow wallpaper
> and slideshow media frame, the first pointing to a directory 100 images big
> (15 minute timer) and the later to a folder 60000 images large (30 second
> timer). I wonder whether this might be a different bug altogether.

OK, have you try the this bug on intel graphic card? I have such huge issue on intel graphic card with neon 5.10.4.
Comment 85 TOM Harrison 2017-07-24 12:54:39 UTC
(In reply to Mircea Kitsune from comment #83)
> (In reply to TOM Harrison from comment #82)
> 
> I'm not getting any excessive CPU usage. I have both a slideshow wallpaper
> and slideshow media frame, the first pointing to a directory 100 images big
> (15 minute timer) and the later to a folder 60000 images large (30 second
> timer). I wonder whether this might be a different bug altogether.

OK, never mind, CPU usage is drop on my nvidia card machine. I do not know that is relative the latest kde update or the qt5 comment issue.
I will let you know that it is solve on the Intel graphic card machine or not.
Sorry for bothering.
Comment 86 Mircea Kitsune 2017-07-24 14:53:54 UTC
(In reply to TOM Harrison from comment #84)

I have an AMD video card, using the free video drivers on RadeonSI. If it's driver related it's most likely a different bug.
Comment 87 TOM Harrison 2017-07-25 02:02:12 UTC
Created attachment 106847 [details]
unfortunately still using almost single core on plasmashell
Comment 88 TOM Harrison 2017-07-25 02:37:33 UTC
Created attachment 106848 [details]
callgrind analysis on machine that has such issue.

hope it will help.
Comment 89 TOM Harrison 2017-07-25 03:46:49 UTC
I report a new bug about that. sorry about bothering.
Comment 90 David Edmundson 2017-07-25 09:58:22 UTC
Do people here have any applets on their desktop, in particular system monitors or other monitors.
Comment 91 Mircea Kitsune 2017-07-25 10:35:24 UTC
(In reply to David Edmundson from comment #90)

I have several widgets; Please see the screenshot I attached (first file) which shows what plasmoids are on my desktop. Most break once Plasma decides to go black then crash, such as corrupt graphics or missing text.
Comment 92 Paul 2017-07-25 10:43:52 UTC
(In reply to David Edmundson from comment #90)
> Do people here have any applets on their desktop, in particular system
> monitors or other monitors.

If you ask in relation to the high CPU utilisation (as opposed to the memory leak this bug report morphed into), no.  Nothing over and above the "standard" KDE panel.
Comment 93 sparhawk 2017-07-28 01:18:47 UTC
(In reply to David Edmundson from comment #90)
> Do people here have any applets on their desktop, in particular system
> monitors or other monitors.
I presented a minimal example in comment #1, but I think the bug was slightly intermittent, so my comments about the color picker plasmoid were incorrect. Here is an even more minimal ~/.config/plasma-org.kde.plasma.desktop-appletsrc where the CPU bug is still present. This is the entire file, and you can see there are no plasmoids. As mentioned earlier, the slide interval is ~10 minutes.

[Containments][139]
activityId=90a9313e-ad43-4d01-b35a-9b9094162ce1
formfactor=0
immutability=1
lastScreen=4
location=0
plugin=org.kde.desktopcontainment
wallpaperplugin=org.kde.slideshow

[Containments][139][Wallpaper][org.kde.slideshow][General]
FillMode=1
SlideInterval=610
SlidePaths=/home/sparhawk/HDD/Personal/Pictures/Wallpapers/Plasma_current
height=1080
width=1920

[Containments][7]
activityId=90a9313e-ad43-4d01-b35a-9b9094162ce1
formfactor=0
immutability=1
lastScreen=0
location=0
plugin=org.kde.desktopcontainment
wallpaperplugin=org.kde.slideshow

[Containments][7][Wallpaper][org.kde.slideshow][General]
FillMode=1
SlideInterval=601
SlidePaths=/home/sparhawk/HDD/Personal/Pictures/Wallpapers/Plasma_current
height=1080
width=1920
Comment 94 Koen 2017-07-28 07:56:40 UTC
I'm also just using color picker and have the CPU problem.
Comment 95 Mircea Kitsune 2017-07-28 20:01:14 UTC
Not sure how much insight this offers at the moment, but just in case; I'm running "dmesg -w" from another machine in order to monitor an unrelated GPU crash. With this occasion I noticed that, during the time the wallpaper and photo frame widget go black, the following message is printed non-stop by dmesg, which only stops after plasmashell has crashes and restarted:

[95823.264112] radeon 0000:03:00.0: va above limit (0x00200A47 >= 0x00200000)
Comment 96 rооt 2017-07-29 16:04:14 UTC
Look at the difference in CPU load between
Mesa 17.1.4 http://i.imgur.com/RKRhofZ.png
and Mesa 17.2.0-rc1 http://i.imgur.com/iN50SqS.png

i5-3570K and integrated graphics intel hd 4000
Comment 97 David Edmundson 2017-07-30 22:36:13 UTC
*** Bug 368838 has been marked as a duplicate of this bug. ***
Comment 98 Christoph Feck 2017-08-01 18:15:51 UTC
*** Bug 382262 has been marked as a duplicate of this bug. ***
Comment 99 Vincent Petry 2017-08-02 09:36:52 UTC
Observed today as well, several times. It started happening after I set my wallpaper to slideshow and to change every 2 hours. I believe the CPU spike happens after 2 hours at the time it would switch the wallpaper but didn't actually switch it (needs confirmation).

Once the plasmashell process went to 100% CPU, then I rebooted.
After a while it went to 50% CPU.

My setup:
- Dell XPS 13 Dev edition 9333
- openSUSE Tumbleweed
- i915 driver for Intel HD 4400 GPU (00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09))
- Xorg settings for GPU: AccelMethod=sna and TearFree=true
- Plasma 5.10.4
- no widgets on the desktop, only wallpaper with slideshow mode
- "system load" widget in taskbar
Comment 100 Christoph Feck 2017-08-02 11:07:26 UTC
*** Bug 382687 has been marked as a duplicate of this bug. ***
Comment 101 David Edmundson 2017-08-04 09:28:37 UTC
*** Bug 383111 has been marked as a duplicate of this bug. ***
Comment 102 adr.fantini 2017-08-07 09:27:53 UTC
I'm also affected on my Dell XPS 9550, suing the Intel modesetting driver. For me it's just sufficient to have the slideshow wallpaper active, no other plasmoid or panel setting needs to be active.

powerstat shows a very high GPU usage as well as a large number of IRQs. Killing plasmashell of course stops the problem.

I believe this is quite more serious than a NORMAL bug. This seems to affect all systems running the latest software and, for notebooks in particular, makes Plasma with a slideshow background completely unusable due to the heat generated and the drastically shorter battery life.
Comment 103 David Edmundson 2017-08-07 20:12:21 UTC
Bah, even if I force a threaded render loop I don't get into this bit of code.

I need someone with debug symbols in Qt to do the following:

Start plasmashell in gdb
recreate the situation
hit control+c and copy the following

set pagination off
set logging on
break QSGGuiThreadRenderLoop::maybeUpdate
commands
thread apply all bt
end
break QSGGuiThreadRenderLoop::exposureChanged
commands
thread apply all bt
end
continue

Then upload gdb.txt or send it to me.
Thanks in advance.
Comment 104 rооt 2017-08-08 01:45:51 UTC
Created attachment 107137 [details]
gdb.txt

Is this on Virtualbox, is it okay?
Comment 105 TOM Harrison 2017-08-08 02:05:39 UTC
Created attachment 107138 [details]
gdb.txt from laptop with Intel graphic card.
Comment 106 David Edmundson 2017-08-08 09:04:48 UTC
Thanks but my instructions were bad. 

Both of those only contain a single backtrace, which isn't enough. That's my fault. Sorry

@Tom I also need these breakports added after you're reproducing the issue, your breakpoints were set on load.


set pagination off
set logging on
break QSGGuiThreadRenderLoop::maybeUpdate
commands
thread apply all bt
continue
end
break QSGGuiThreadRenderLoop::exposureChanged
commands
thread apply all bt
continue
end
continue
Comment 107 TOM Harrison 2017-08-08 10:32:56 UTC
Created attachment 107151 [details]
gdb.txt with newer information.
Comment 108 rооt 2017-08-08 11:16:02 UTC
Created attachment 107152 [details]
gdb.txt
Comment 109 Vova Mshanetskiy 2017-08-18 12:45:06 UTC
Created attachment 107349 [details]
strace of kwin_x11

It looks like i am also affected by this issue. I have two systems, which are almost identical in terms of software (both openSUSE Tumbleweed on one of the latest snapshots) and settings, but one of them is affected by this bug, and the other one is not. The unaffected system has NVIDIA GTX660 GPU, and the affected one has Intel HD Graphics 630.

Also, my experience is a bit different. For me, it is actually kwin_x11, what produces the most CPU usage. However, even if i set desktop background to solid black color, KWin still starts to use a lot of CPU after several hours. Restarting KWin brings CPU usage to normal for several more hours. Setting wallpaper to slideshow just causes the CPU usage to rise immediately (and requires setting wallpaper back to solid color and restarting Plasma to return CPU usage to normal). When KWin's CPU usage rises, strace'ing kwin_x11 shows a lot of lines with DRM_IOCTL_I915_GEM_... (see attachment).

So, maybe this bug is less Plasma-related and more KWin-related?.. Or am i just affected by a different bug? Anyway, if a can help by e.g. collecting some logs on both affected and unaffected system, let me know.
Comment 110 Guo Yunhe 2017-08-19 17:19:45 UTC
Maybe the same issue. I have three monitors. All of them use slideshow wallpaper of 100+ photos (usually smaller than 1200x1200px). After 5 minutes, plasmashell will eat up all CPU (Core i7 4710HQ) and RAM (8GB). Then it is killed by system.

openSUSE Tumbleweed
KDE 5.10.4
Qt 5.9
Comment 111 David Edmundson 2017-08-19 22:35:45 UTC
@ Vova Mshanetskiy 

Only non threaded render loops are affected.

Kwin's CPU is higher because plasmashell is redrawing windows like crazy.
As to why Plasmashell is redrawing like crazy, I don't exactly know. See earlier comments from me.

Logs won't help, someone being affected and debugging it will.
Comment 112 Todor Gyumyushev 2017-08-21 17:54:07 UTC
(In reply to Antonio Rojas from comment #60)
> (In reply to David Edmundson from comment #59)
> > Can someone try to rebuild Qt without the commit in #50 please
> 
> Archlinux users can test the build from
> http://pkgbuild.com/~arojas/qt5-declarative-5.9.1-3.1-x86_64.pkg.tar.xz

I have the plasmashell memory leak but your package solved it.
Can you share PKGBUILD or patch details ?
Comment 113 mcgyver 2017-08-24 11:15:59 UTC
The bug on he memory leak in Qt seems to be stuck: https://bugreports.qt.io/browse/QTBUG-62117

And I am still experiencing the same problem with the latest release.
Would be possible to provide some more information on the Qt bug thread, and/or provide us with the patch used to create the test solution (so we can patch it manually):

http://pkgbuild.com/~arojas/qt5-declarative-5.9.1-3.1-x86_64.pkg.tar.xz

Thank you
Comment 114 mcgyver 2017-08-24 14:10:16 UTC
I tried to reconstruct the PKGBUILD file and a patch file from the description of the error at https://bugreports.qt.io/browse/QTBUG-62117

In particular, I patched the source code reverting the commit eeb320bbd8763f3e72f79369cc3908e999a0da3c (with the diff file from http://code.qt.io/cgit/qt/qtdeclarative.git/patch/?id=eeb320bbd8763f3e72f79369cc3908e999a0da3c )

However, I could only get a package up to date with a (small-ish) memory leak as described earlier: every time the image in the slideshow is updated, some additional KB of memory are allocated and never released.

I am reverting back to the qt5-declarative published at http://pkgbuild.com/~arojas/qt5-declarative-5.9.1-3.1-x86_64.pkg.tar.xz

If anyone has a better idea on how to proceed to update qt5-declarative, or how to correct the KDE infrastructure to have fully updated packages and no memory leak, please post the solution!
Comment 115 Mircea Kitsune 2017-08-24 21:05:22 UTC
openSUSE Tumbleweed reverted the guilty commit about 3 weeks ago. I can only say it's solved the problem for me.
Comment 116 mcgyver 2017-08-25 14:21:18 UTC
ok... so, it seems that the patch for the memory leak problem is solved in the Qt git repository, but the patch has not yet reached the Arch linux package repository.

I am still seeing small memory increases, but I am not sure if that is connected with the slideshow bug, or it is a real memory usage.

I'll keep monitoring this and report if I find anything new.
When are packages re-compiled from the source repositories?
Is there a known timeline or schedule?

Thanks everyone!
Comment 117 Antonio Rojas 2017-08-26 19:54:06 UTC
Arch users, please test qt5-declarative 5.9.1-5
Comment 118 sparhawk 2017-08-26 22:43:36 UTC
(In reply to Antonio Rojas from comment #117)
> Arch users, please test qt5-declarative 5.9.1-5

I guess this relates to the memory leak. FWIW this doesn't fix the original CPU bug.
Comment 119 Kishore Gopalakrishnan 2017-08-27 01:33:42 UTC
(In reply to Antonio Rojas from comment #117)
> Arch users, please test qt5-declarative 5.9.1-5

Unfortunately, it doesn't fix the bug. RAM usage still increases with time. however, the version you linked in comment 60 fixes it.
Comment 120 sunweb 2017-08-30 09:29:26 UTC
Same here, high CPU usage, though in my case i don't have memory leak.
Reproducable with a new user and just setting up a Slideshow. Changing to Picture and logout/login takes CPU load down, each hungry process dropped from ~8% cpu utlization to below 0.8%.

Kwin 5.10.5-1
Qt 5.9.1
Plasma 5.10.5
Comment 121 David Edmundson 2017-08-30 09:52:29 UTC
Can people please verify if 22f0b13f46f94ec97198e754a72069040a43e071 in QtDeclarative fixes their problem.
Comment 122 TOM Harrison 2017-09-04 08:52:51 UTC
according to my test, the It just reduced some of the memory leak, but still increase memory usage after a long time.
CPU consume still exist, plasmashell did not drop to 0% when picture did not change.
Comment 123 David Edmundson 2017-09-04 11:06:27 UTC
*** Bug 361074 has been marked as a duplicate of this bug. ***
Comment 124 Vova Mshanetskiy 2017-09-22 11:36:59 UTC
It looks like i was able to found a workaround for this issue. Here is what i did.

First i enabled KWin effect which highlights areas of screen when they are redrawn. As expected, the whole screen was constantly flashing. For me it looked like some animation is constantly playing, so i decided to try to edit /usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml to disable all animations. This worked, and i was able to narrow modifications down to changing fadeFillMode() function as follows:

function fadeFillMode() {
    fadeAnim.running = false
    swapImages()
    currentImage.sourceSize = otherImage.sourceSize
    sourceSizeTimer.stop()
    currentImage.source = modelImage
    currentImage.opacity = 1 // <--- replaced 0 with 1 in this line
    otherImage.z = 0
    currentImage.fillMode = fillMode
    currentImage.z = 1

// --- commented out the rest of function ---
/*
    // only cross-fade if the new image could be smaller than the old one
    fadeOtherAnimator.enabled = Qt.binding(function() {
        return currentImage.paintedWidth < otherImage.paintedWidth || currentImage.paintedHeight < otherImage.paintedHeight
    })

    fadeAnim.running = Qt.binding(function() {
        return currentImage.status !== Image.Loading && otherImage.status !== Image.Loading
    })
*/
}

After modifying the file and restarting Plasma Shell the issue was gone: screen redraws only occurred once in a second and CPU usage was down to 0%. That redrawing occurred because of a plasmoid update, which is normal. However, there is one thing that i noted: whenever that plasmoid updates, the whole screen is redrawn, while on my other PC, which was never affected by this issue (see comment 109), only the bottom panel where the same plasmoid is located is redrawn.

By the way, there is one other glitch which occurs on both of my PCs and might be related. When i log in or restart Plasma Shell, the first slideshow image appears immediately but then it immediately cross-fades into a new slideshow image. Like if the first image times out immediately.
Comment 125 TOM Harrison 2017-09-22 13:54:36 UTC
seems not working on nvidia card. After modified and restart plasmashell. still using high CPU.
Comment 126 Vova Mshanetskiy 2017-09-22 14:00:01 UTC
(In reply to TOM Harrison from comment #125)
> seems not working on nvidia card. After modified and restart plasmashell.
> still using high CPU.

Well, you can try to also modify fadeWallpaper() and fadeSourceSize() in a similar way. I have an Intel GPU. My other PC with NVIDIA is not affected at all.
Comment 127 TOM Harrison 2017-09-22 14:00:54 UTC
(In reply to TOM Harrison from comment #125)
> seems not working on nvidia card. After modified and restart plasmashell.
> still using high CPU.

OK, forget what I say, The workaround working. I has another cpu consume issue.
I'm sorry.
Comment 128 Paul 2017-09-22 14:55:18 UTC
(In reply to Vova Mshanetskiy from comment #124)
> By the way, there is one other glitch which occurs on both of my PCs and
> might be related. When i log in or restart Plasma Shell, the first slideshow
> image appears immediately but then it immediately cross-fades into a new
> slideshow image. Like if the first image times out immediately.

I was seeing that behaviour a while ago... see bug #379580
Comment 129 Christoph Feck 2017-09-28 23:56:53 UTC
*** Bug 385130 has been marked as a duplicate of this bug. ***
Comment 130 Christoph Feck 2017-10-04 11:33:41 UTC
*** Bug 385350 has been marked as a duplicate of this bug. ***
Comment 131 Christoph Feck 2017-10-12 19:56:40 UTC
Can anyone running Qt 5.9.2 check the status of this ticket? It looks like I incorrectly merged the "high CPU" and the "high memory" issues related to the Plasma slideshow.

If either of them is still present, please add a comment.
Comment 132 grmat 2017-10-12 20:15:46 UTC
(In reply to Christoph Feck from comment #131)
> Can anyone running Qt 5.9.2 check the status of this ticket? [...]
> If either of them is still present, please add a comment.

Still having high GPU load when a slideshow is set.

Qt 5.9.2
Plasma 5.11.0
Comment 133 gertlink_nospam 2017-10-13 06:44:43 UTC
Still having the high memory issue (but no high cpu usage) when a slideshow is set in the picture frame plasmoid.

Qt 5.9.2
Plasma 5.11.0

as guest in virtualbox
Comment 134 sparhawk 2017-10-14 02:01:33 UTC
(In reply to Christoph Feck from comment #131)
> Can anyone running Qt 5.9.2 check the status of this ticket? It looks like I
> incorrectly merged the "high CPU" and the "high memory" issues related to
> the Plasma slideshow.
> 
> If either of them is still present, please add a comment.

I'm running Qt 5.9.2, and can confirm that the CPU bug is still present.

However, the CPU loads from the first comment in this thread have changed slightly. Now it's worse for plasmashell, but better for the others.

* 98% for plasmashell
* 15% for kwin_x11
* 15% for Xorg -nolisten tcp -auth /var/run/sddm/{<random_string>} -background none -noreset -displayfd 18 -seat seat0 vt1

Switching to a static image makes it 14% / 19% / 10%.
Comment 135 sparhawk 2017-10-14 02:18:59 UTC
(In reply to Vova Mshanetskiy from comment #124)
> It looks like i was able to found a workaround for this issue.

I can confirm that this fixes the bug for me. Plasmashell CPU usage drops to 6%!
Comment 136 Ruedi Hofer 2017-10-22 14:28:39 UTC
Dear all, 
suffering from a huge memory leak when using "media frame widget", I'm coming from Bug 382262 and confirm that memory leak still present. 16G Ram are eaten up in less than 2 hours. Restarting plasmashell releases the memory, after "media frame widget" had been closed.

Using 
kubuntu Artful ppa backports landing
Plasma 5.11.1
KDE Frameworks 5.39.0
Qt 5.9.1
Kernel 4.13.0-16
OS 64bit.
Comment 137 Koen 2017-10-24 13:17:39 UTC
I updated opensuse tumbleweed yesterday. Comes with qt 5.9.1 and for me the cpu problem is no longer terrorizing my laptop. I just use the a picture as screen saver and I have a bunch of folder widgets on my plasma desktop.
Comment 138 Ruedi Hofer 2017-10-25 20:01:27 UTC
Even with the latest KDE from kubuntu ppa landing, the media frame widget eats up my memory.

kubuntu Artful ppa backports landing
Plasma 5.11.2
KDE Frameworks 5.39.0
Qt 5.9.1
Kernel 4.13.0-16
OS 64bit.

Mentioned in Bug 382262 which is marked duplicate from this bug.
Comment 139 sparhawk 2017-10-30 06:03:19 UTC
(In reply to sparhawk from comment #135)
> (In reply to Vova Mshanetskiy from comment #124)
> > It looks like i was able to found a workaround for this issue.
> 
> I can confirm that this fixes the bug for me. Plasmashell CPU usage drops to
> 6%!

This fix no longer seems to work in Plasma 5.11.2. CPU usage drops, but the wallpaper is blank.
Comment 140 TOM Harrison 2017-10-30 09:37:47 UTC
(In reply to sparhawk from comment #139)
> (In reply to sparhawk from comment #135)
> > (In reply to Vova Mshanetskiy from comment #124)
> > > It looks like i was able to found a workaround for this issue.
> > 
> > I can confirm that this fixes the bug for me. Plasmashell CPU usage drops to
> > 6%!
> 
> This fix no longer seems to work in Plasma 5.11.2. CPU usage drops, but the
> wallpaper is blank.

I am still using this patch. It fix for me, wallpaper is not black.
Comment 141 Vova Mshanetskiy 2017-10-30 11:53:48 UTC
I have found two other ways to trigger the bug. If you want to test them, you must have my workaround from comment 124 applied before you begin (it still works for me on Plasma 5.11.2, Qt 5.9.2). I also suggest enabling screen redraw highlighting effect in system settings for better visibility.

I have edited /usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml again and added the following code before the final closing curly brace:

    MouseArea {
        anchors.fill: parent
        onClicked: action_next()
    }

Essentially this lets you trigger the "Next image" popup menu action by just clicking anywhere on the desktop. Now, when i click the desktop once, the wallpaper cross-fades into a new wallpaper normally. However, if i click multiple times before the cross-fade animation finishes, screen redraws (and CPU usage) do not stop after the animation finishes. This can be fixed only by restarting Plasma Shell.

In the last paragraph of my comment 124 i mentioned the startup glitch which, i thought, could be related. Now i am even more convinced that it is. My further tests showed, that actually Plasma Shell starts and stops the cross-fade animation much more than once during startup. It probably interrupts it in the middle at least once, which triggers the bug, just like me clicking the desktop multiple times in a row.

The second way i have just found accidentally is not in Plasma Shell, but in the System Settings application. I just have to open it and move the mouse up and down a little above the new sidebar on the left. After several hint popups appear, the whole screen starts to constantly redraw, just like with Plasma and slideshow wallpaper. And systemsettings5 is at the top of CPU usage table. Fixed by minimizing or closing System Setting.
Comment 142 Vova Mshanetskiy 2017-10-30 12:28:58 UTC
Created attachment 108642 [details]
Bug demonstration using qmlscene

I have attached a .qml file, which can trigger the same bug when started using qmlscene (i.e. qmlscene bug.qml). I have tried to repeat, what Plasma's slideshow wallpaper does. When you run it, a small window with red content will appear. If you click it, it will cross fade into blue. If you click it again, it will cross-fade into red and so forth. However, if you interrupt it in the middle of animation by clicking again, the constant redraw / CPU usage bug manifests itself. After closing the qmlscene window, everything is back to normal.

I have tried to kill both plasmashell and kwin_x11 to make sure they do not interfere with the experiment, but that did not change anything.

Can someone else test this? If it triggers constant redraws for you to, then it is probably a Qt bug.
Comment 143 TOM Harrison 2017-10-30 13:45:52 UTC
I can confirm this could re-produce the cpu consume issue by using the bug.qml.
I test on latest neon iso.

(In reply to Vova Mshanetskiy from comment #142)
> Created attachment 108642 [details]
> Bug demonstration using qmlscene
> 
> I have attached a .qml file, which can trigger the same bug when started
> using qmlscene (i.e. qmlscene bug.qml). I have tried to repeat, what
> Plasma's slideshow wallpaper does. When you run it, a small window with red
> content will appear. If you click it, it will cross fade into blue. If you
> click it again, it will cross-fade into red and so forth. However, if you
> interrupt it in the middle of animation by clicking again, the constant
> redraw / CPU usage bug manifests itself. After closing the qmlscene window,
> everything is back to normal.
> 
> I have tried to kill both plasmashell and kwin_x11 to make sure they do not
> interfere with the experiment, but that did not change anything.
> 
> Can someone else test this? If it triggers constant redraws for you to, then
> it is probably a Qt bug.
Comment 144 David Edmundson 2017-11-01 14:29:48 UTC
*** Bug 385970 has been marked as a duplicate of this bug. ***
Comment 145 Brom 2017-11-03 17:13:33 UTC
The high cpu usage on slideshow occurs on Kubuntu 17.10 too, both if it is activated as desktop wallpaper and on the lock screen.

KDE Plasma Version 5.10.5
KDE Frameworks Version 5.38.0
Qt Version: 5.9.1

On the lock screen the high load is shown to originate from kscreenlocker_greet. It took me some time to find this bug report.
Comment 146 Will Carroll 2017-11-07 14:18:36 UTC
Bug occurs on one of my systems but not the other. Both systems running Arch Linux with kernel 4.13.9 with Plasma 5.11.2.

System Bug Appears On:
 * Intel i7-4770k
 * nVidia GTX 780 w/ Nouveau Driver
 * 2 x 2560x1440 Displays, slideshow running on both

System Bug Doesn't Appear On:
 * Intel i5-4200U w/ Intel Integrated Graphics
 * 1 x 2560x1440 Display, scaled at 1.5x

Both systems have images on the same drive as root, but a different partition.
On the system the bug appears on, CPU usage sits at 35%, memory used by plasmashell alone ramped up to 3.5GiB within 5 minutes of log on until plasmashell was unusable.
Comment 147 Vova Mshanetskiy 2017-11-07 15:14:29 UTC
I have found another workaround for the high CPU usage issue. I have never had any RAM usage problems, but i suggest those, who suffer from high RAM usage issue, to try it too.

You have to edit /usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml according to the following patch:

--- main.qml 2017-10-24 14:34:25.000000000 +0300
+++ main-na.qml 2017-11-06 13:16:12.944001093 +0200
@@ -173,16 +173,18 @@
         running: false
 
         ParallelAnimation {
-            OpacityAnimator {
+            NumberAnimation {
                 target: currentImage
+                property: "opacity"
                 from: 0
                 to: 1
                 duration: fadeOtherAnimator.duration
             }
-            OpacityAnimator {
+            NumberAnimation {
                 id: fadeOtherAnimator
                 property bool enabled: true
                 target: otherImage
+                property: "opacity"
                 from: 1
                 // cannot disable an animation individually, so we just fade from 1 to 1
                 to: enabled ? 0 : 1

This replaces OpacityAnimators used to animate slide changes with equivalent NumberAnimations (NumberAnimations are less efficient/performant though). The same action fixes my bug.qml from comment 142, by the way.
Comment 148 Paul 2017-11-07 16:09:57 UTC
(In reply to Vova Mshanetskiy from comment #147)
> I have found another workaround for the high CPU usage issue.

Yes, just tried that and it fixes the high CPU utilisation. (Likewise, I was not seeing the RAM issue).

Using:
Plasma 5.11.2
Frameworks: 5.39.0
Qt: 5.9.2

Additionally it fixes "the first slideshow image appears immediately but then it immediately cross-fades into a new slideshow image" problem you wrote of in comment #124
and I reported as bug #379580
Comment 149 Vova Mshanetskiy 2017-11-07 16:19:07 UTC
(In reply to Paul from comment #148)
> Additionally it fixes "the first slideshow image appears immediately but
> then it immediately cross-fades into a new slideshow image" problem you
> wrote of in comment #124
> and I reported as bug #379580

Actually it should not fix this. Does not fix for me. This modification should not change Plasma behavior an any noticeable way, except for, maybe, making slideshow animations a little less smooth. If you have a not-very-fast PC, this might result in that you do not get to see the first slide at all.
Comment 150 Paul 2017-11-07 16:40:36 UTC
(In reply to Vova Mshanetskiy from comment #149)
> Actually it should not fix this. Does not fix for me. This modification
> should not change Plasma behavior an any noticeable way, except for, maybe,
> making slideshow animations a little less smooth. If you have a
> not-very-fast PC, this might result in that you do not get to see the first
> slide at all.

Since applying your patch I've not seen the 2 consecutive images problem :)

So... bonus, I'm happy. Thanks!

It's running on quite an elderly Athlon 64 x2 5600+ system. What also may be at play is I'd also previously changed all instances of "duration:" and "interval:"
to a fixed value of " = 100"

If I revert back to OpacityAnimator then I again see the 2 consecutive images.
Comment 151 David Edmundson 2017-11-08 00:47:10 UTC
@ Vova Mshanetskiy 

Thanks so much for your investigations. It's /really/ appreciated.

It makes sense with some findings I have in other bugs, mostly with the tiny file transfer spinner; as though something about animator triggers excessive re-rendering.

We have ~40 animators throughout Plasma code. I don't really want to go down the path of porting them all back as, like you say, this was done (ironically) for the performance gains - we do need to look further into the root cause within QQuickWindow and the animators themselves.
Comment 152 David Edmundson 2017-11-08 00:53:28 UTC
Can you also run  108642 with QSG_INFO=1
Comment 153 Vova Mshanetskiy 2017-11-08 12:35:41 UTC
Created attachment 108739 [details]
Output of 108642 with QSG_INFO=1 on affected system

I also tried running with QSG_VISUALIZE=changes. What is interesting, is that after i double click the window and the animation finishes, Qt's own visualization shows no more changes, while KWin's highlight-redraws effect shows constant redraws. Also, the visualization looks a bit different when running the original attachment 108642 [details] and a modified version with OpacityAnimators replaced with NumberAnimations. With OpacityAnimatiors the last change (when the animation finishes) is highlighted with a solid color, but with NumberAnimations the last change is highlighted in a striped pattern. According to docs this means different things.

Now, a bit of my background. I am a C++ developer currently working on a Qt/QML mobile app. It is my first time experience with QtQuick, but i am not new to Qt. I have tried to use Animators in several places in my project, and they never worked for me. Sometimes they just do not work, sometimes they leave the whole animated part of UI blank (while i am able to interact with it), sometimes they work or they don't depending on how i order them inside a ParallelAnimation, sometimes it depends on the value of duration property. It looks like QtQuick does not like something about hardware of my work PC, but that also happens on my Android phone. And then i have this bug. For me it looks like Animators are just buggy right now. I think i will stay away from them for a few releases of Qt.
Comment 154 David Edmundson 2017-11-08 14:11:53 UTC
Do you build your own Qt?

Also, sorry to do this, but can you regenerate that last one with:

QT_LOGGING_RULES=qt.scenegraph.general.debug=true qmlscene bug.qml

QSG_INFO was the old thing, it remains for backwards compatibility, but it gets activated at the wrong point after the one line I want to see.
Comment 155 Vova Mshanetskiy 2017-11-08 14:25:06 UTC
Created attachment 108746 [details]
Output of 108642 with QT_LOGGING_RULES=qt.scenegraph.general.debug=true on affected system

The output is identical to the previous one. Only the GL_EXTENSIONS line is different, but it looks like it is only different in ordering.

No, i/we do not build Qt. My PC is using official openSUSE build, and for my Android development i use LGPL package from qt.io.
Comment 156 Will Carroll 2017-11-13 02:01:39 UTC
(In reply to Will Carroll from comment #146)
> Bug occurs on one of my systems but not the other. Both systems running Arch
> Linux with kernel 4.13.9 with Plasma 5.11.2.
> 
> System Bug Appears On:
>  * Intel i7-4770k
>  * nVidia GTX 780 w/ Nouveau Driver
>  * 2 x 2560x1440 Displays, slideshow running on both
> 
> System Bug Doesn't Appear On:
>  * Intel i5-4200U w/ Intel Integrated Graphics
>  * 1 x 2560x1440 Display, scaled at 1.5x
> 
> Both systems have images on the same drive as root, but a different
> partition.
> On the system the bug appears on, CPU usage sits at 35%, memory used by
> plasmashell alone ramped up to 3.5GiB within 5 minutes of log on until
> plasmashell was unusable.

Update: bug started occurring a few days ago on single display system after a reboot.
Comment 157 David Edmundson 2017-11-13 09:47:07 UTC
This report is too messy and drowned in spam.
I've split things into two smaller reports :

386844 (memory leak fixed in 5.9.2)

and 

386846 (high CPU *specfically with animators*)
Comment 158 Mario 2017-12-12 10:09:25 UTC
In my laptop doesn't works. There's always memory leak with qt 5.9.3 and Plasma 5.11.3. I've a hybrid intel/nvidia graphic card, I7 proc 8x and 15 GB of RAM. I've deleted any plasma config file, but the bug is always there...
Comment 159 gertlink_nospam 2017-12-12 10:13:22 UTC
The same here. Memory leak bug is still existing.
Plasma 5.11.4
Qt 5.9.3
Comment 160 Ruedi Hofer 2017-12-14 10:23:44 UTC
Why resolved & fixed when comments say that it is still not working?
Comment 161 djancak 2017-12-18 09:32:25 UTC
(In reply to Ruedi Hofer from comment #160)
> Why resolved & fixed when comments say that it is still not working?

I wondered this as well. My KDE Neon installation is having the same issue.
Comment 162 Patrick Silva 2017-12-18 09:46:20 UTC
reopening because it's not fixed...
Comment 163 David Edmundson 2017-12-18 11:12:31 UTC
The leak this was tracking *is* fixed.

If you have another leak, please create a new bug with new information.
Ideally a callgrind log.
Comment 164 daniel.armbrust.list 2017-12-27 15:42:44 UTC
I'm not sure what leaks were or were not fixed, but the primary issue that got duped here - the desktop slideshow being completey unusable, is still fully broken.

Enabling a media frame will cause KDE to leak memory so fast it will crash most systems in 20 minutes.

What do you need to see to get this properly fixed?  Its so completely trivial to reproduce, I don't understand why folks are waiting on logs again to fix this nasty regression.
Comment 165 Christoph Feck 2018-01-10 22:05:28 UTC
Daniel, see bug 368838, which for some reason is the new ticket about this issue. I remember seeing someone mentioning it doesn't happen with Qt 5.10, but I cannot find it right now.
Comment 166 Brendon Higgins 2018-01-17 17:37:18 UTC
(In reply to Christoph Feck from comment #165)
> Daniel, see bug 368838, which for some reason is the new ticket about this
> issue. I remember seeing someone mentioning it doesn't happen with Qt 5.10,
> but I cannot find it right now.

Hi, Christoph. You're probably thinking of bug 386846, which is one of two David Edmundson split this bug into. See comment 157. Qt 5.10 being a potential fix is mentioned there. (I hope it's so. I have plasma, running under virtual box, using damn near 100% of every core when my background is in slideshow mode.)