Version: (using KDE 4.3.1) OS: Linux Installed from: Debian testing/unstable Packages Desktop Settings (the one you get to by right-clicking on the background, not the one you get to by systemsettings): I've set "Wallpaper" to "Slideshow", and I have pointed it to a directory of my photographs (1.5MB jpegs or so from 6MP camera). Every time the wallpaper slideshow switches the picture, my system seems to freeze for a few seconds. Input events are queued but not processed, etc. Perhaps no other X ops are permitted? At least a way of turning off the fade-out-and-in thing would help: just switch the wallpaper NOW in one step. I have "Desktop effects" completely disabled through systemsettings, but apparently the wallpaperer doesn't care. Thanks! -Ben Also: xorg 7.4 xserver-xorg-video-intel 2.9.0
Have exactly the same problem on nvidia card. xorg: 1:7.4+4 nvidia-glx: 185.18.36-2 Isn't this the same problem as bug 209186 ?
*** Bug 214702 has been marked as a duplicate of this bug. ***
I have this problem too.
Is this bug still valid with kde 4.4.4 or kde 4.5beta ?
*** Bug 209186 has been marked as a duplicate of this bug. ***
Seems better under 4.4.4 (thanks!), but still not great. Why not have the option of not animating it? With today's 15MP cameras, it seems that this will always take up quite a bit of CPU, won't it?
I was working good in previous kde versions, probably 4.2, It's a 4.3 regression
*It Sorry for mistake :]
*** Bug 244563 has been marked as a duplicate of this bug. ***
*** Bug 222313 has been marked as a duplicate of this bug. ***
I'm also having this problem on one system but not the other and can perhaps add some vital detail. Both systems have nVidia cards and both use the nv driver. Both are Fedora 13 running KDE 4.4.5. One has desktop effects enabled and works great (no delay in wallpaper transitions, no excessive CPU load). The other system cannot use desktop effects because it's a 3-head xinerama system and transitions there typically take 5-10 seconds and cause all other processes to suffer intensely as the load spikes during that time.
is it still valid with newer versions? (kde/drivers...)
This is not resolved yet, the problem still persists. Well, at least until KDE 4.6.5, which is the version I'm using. People who are running more up to date versions, please comment. I would agree with the solution proposed by the OP, which is to disable the fade out/in effect and just switch the photos. Of course the fade effect makes the transition more pleasant, but not if it freezes the computer while the photo changes. If this can not be fixed, I think it's better to remove the fade effect.
"With today's 15MP cameras, it seems that this will always take up quite a bit of CPU, won't it?" the image is scaled to the screen's resolution, in a non-blocking thread, before it is painted. so this doesn't matter (other than the CPU time to scale it the first time)
*** Bug 248122 has been marked as a duplicate of this bug. ***
*** Bug 276116 has been marked as a duplicate of this bug. ***
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham