| Summary: | [Regression] High CPU when background is set to slideshow | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | sparhawk <kdebugs> |
| Component: | Image & Slideshow wallpaper plugins | Assignee: | Marco Martin <notmart> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | CC: | 460163461, adr.fantini, arojas, brendon, brom+kde, bugs.kde.org.onion358, bugs.kde.org, bugseforuns, cerebellum, criguada, daniel.armbrust.list, daniel.lichtenberger, dcoffey095, djancak, ervin, gertlink_nospam, gilaldpellaeon, godlike64, grmat, i, jazzvoid, johannes, justus5abbotts, kde, kde, kdebugs, kdejaeger, kevlyn220, kishore96, l12436.tw, lars_kdebugs, luca.forina, mail, mark_p._sanders, matt.scheirer, me, mgulli, mike, nikonovds, phantom4, pip.kde, plasma-bugs, PVince81, rdalek1967, rubin, ruedihofer, sergio.davies, simonandric5, sonichedgehog_hyperblast00, stephan.diestelhorst, sunwebrw, tanjoodo, theare, theivorytower, thomas.bettler, toddrme2178, unrath, vkrevs, vovams163, will.carroll7, wmatex, yodor, yorirou, zrenfire |
| Priority: | NOR | ||
| Version: | 5.10.1 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=378010 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Screenshot of blank wallpaper / media frame
Massif snapshots of the plasmashell process. Massif snapshot w/o eeb320bbd (many pics) Massif snapshot w/o eeb320bbd (2 pics) log output with QT_LOGGING_RULES=qt.scenegraph.renderloop.debug=true Massif analysis, QSG_RENDER_LOOP=basic Massif analysis, QSG_RENDER_LOOP=threaded Add debug in QtDeclarative QSGGuiThreadRenderLoop plasmashell output with qt5-declarative 5.9.1-3 patched with 106799 unfortunately still using almost single core on plasmashell callgrind analysis on machine that has such issue. gdb.txt gdb.txt from laptop with Intel graphic card. gdb.txt with newer information. gdb.txt strace of kwin_x11 Bug demonstration using qmlscene Output of 108642 with QSG_INFO=1 on affected system Output of 108642 with QT_LOGGING_RULES=qt.scenegraph.general.debug=true on affected system |
||
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 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%. 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? > 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. If it's not too much trouble. 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? 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. 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 I have made the change to the main.qml file, restarted plasmashell, activated the slightshow again and the CPU load stays low. (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. 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.
}
(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. (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. 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. (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. (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. (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. 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. (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 (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. 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. 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. 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 (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 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. (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. Given someone says it's a change in Qt can you try list what versions of Qt have and don't have this issue. 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. And the qt version seems to be 5.9.0-1.1 (opensuse tumbleweed latest version) 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. cntrl-esc -> system activity shows 15% htop shows around 120% ... for plasmashell pretty much a few minutes after boot 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. 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. 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.
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. (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.) 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. 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)
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.
*** Bug 382288 has been marked as a duplicate of this bug. *** 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.
*** Bug 382316 has been marked as a duplicate of this bug. *** *** Bug 382413 has been marked as a duplicate of this bug. *** 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.
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 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. 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. And yes, the update is to Qt 5.9.1 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 eeb320bbd8763f3e72f79369cc3908e999a0da3c is potentially relevant. 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. @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. 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. 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 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. (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). *** Bug 381471 has been marked as a duplicate of this bug. *** Can someone try to rebuild Qt without the commit in #50 please (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 Created attachment 106755 [details]
Massif snapshot w/o eeb320bbd (many pics)
In this analysis I've been rapidly changing wallpapers in a random order.
Created attachment 106756 [details]
Massif snapshot w/o eeb320bbd (2 pics)
In this analysis I've been rapidly swapping only two wallpapers.
So it seems like the commit eeb320bbd has indeed introduced this memory leakage. We'll see how it performs in a long term. 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? Also can I have output of QT_LOGGING_RULES=qt.scenegraph.renderloop.debug=true plasmashell from someone with the bug Created attachment 106764 [details]
log output with QT_LOGGING_RULES=qt.scenegraph.renderloop.debug=true
(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. 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.
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.
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. (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. 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 (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. (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 (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. *** Bug 382602 has been marked as a duplicate of this bug. *** Comment 60 fixed the memory leak problem I described in bug 382602. 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.
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. Created attachment 106803 [details]
plasmashell output with qt5-declarative 5.9.1-3 patched with 106799
Thanks everyone. I've forwarded all this information as https://bugreports.qt.io/browse/QTBUG-62117 (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 ? (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. (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. (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. (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. Created attachment 106847 [details]
unfortunately still using almost single core on plasmashell
Created attachment 106848 [details]
callgrind analysis on machine that has such issue.
hope it will help.
I report a new bug about that. sorry about bothering. Do people here have any applets on their desktop, in particular system monitors or other monitors. (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. (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. (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 I'm also just using color picker and have the CPU problem. 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) 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 *** Bug 368838 has been marked as a duplicate of this bug. *** *** Bug 382262 has been marked as a duplicate of this bug. *** 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 *** Bug 382687 has been marked as a duplicate of this bug. *** *** Bug 383111 has been marked as a duplicate of this bug. *** 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. 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. Created attachment 107137 [details]
gdb.txt
Is this on Virtualbox, is it okay?
Created attachment 107138 [details]
gdb.txt from laptop with Intel graphic card.
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 Created attachment 107151 [details]
gdb.txt with newer information.
Created attachment 107152 [details]
gdb.txt
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.
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 @ 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. (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 ? 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 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! openSUSE Tumbleweed reverted the guilty commit about 3 weeks ago. I can only say it's solved the problem for me. 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! Arch users, please test qt5-declarative 5.9.1-5 (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. (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. 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 Can people please verify if 22f0b13f46f94ec97198e754a72069040a43e071 in QtDeclarative fixes their problem. 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. *** Bug 361074 has been marked as a duplicate of this bug. *** 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.
seems not working on nvidia card. After modified and restart plasmashell. still using high CPU. (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. (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. (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 *** Bug 385130 has been marked as a duplicate of this bug. *** *** Bug 385350 has been marked as a duplicate of this bug. *** 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. (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 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 (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%. (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%! 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. 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. 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. (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. (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. 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. 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.
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. *** Bug 385970 has been marked as a duplicate of this bug. *** 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. 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. 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.
(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 (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. (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. @ 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. Can you also run 108642 with QSG_INFO=1 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. 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. 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.
(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. 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*) 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... The same here. Memory leak bug is still existing. Plasma 5.11.4 Qt 5.9.3 Why resolved & fixed when comments say that it is still not working? (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. reopening because it's not fixed... The leak this was tracking *is* fixed. If you have another leak, please create a new bug with new information. Ideally a callgrind log. 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. 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. (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.) |
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.