Version: (using KDE 4.2.85) Installed from: SuSE RPMs If I use the microblogging plasmoid, plasma-desktop is going up to 99% CPU usage making it absolutely unresponsive for some minutes. After some minutes the CPU usage is going back to normal for some time. Removin the plasmoid is an immediate cure to this problem. This is happening with KDE 4.2.87 packages from openSuse UNSTABLE. Plasma theme in use is Air.
define "use": at what point, exactly, does it start sucking cpu? after first configuration? when it actually loads the items? what settings are you using with it? is there a scroll bar displayed when it sucks the cpu like this? and to be 100% certain, it's plasma-desktop and not kio_http that's taking the cpu, correct?
Hi Aaron, yes it's plasma-desktop that's taking the cpu not kio_http. I first had two instances of the plasmoid running (one for identi.ca, one for twitter). Number of items is set to 20, update time at 2 minutes. Because of the number of items, the scroll bar is always visible. I have now removed the two plasmoid, then added only one. I first configured it for identi.ca but couldn't see the effect here. Then I changed API to twitter and it started again. So it seems to be a problem with the twitter engine. I observed that it only happens directly after the load of items (first I see kio_http in top for a short time, than plasma-desktop starts to raise). It occurs to me that the high cpu usage is taking longer the longer the plasmoid is running. Hope that helps somehow.
I've got the same issue, with two microblog applets, both using Twitter (two different accounts). Both are set to display 3 messages, refreshing every 5 minutes. Scrollbar is not always visible, though it may be. I had the same issue in 4.2.3 and now 4.2.87 (Gentoo "kde" overlay). It also occured when I had the two microblogs in a panel, rather than on the desktop. I did not notice any problems with just 1 microblog in KDE 4.2.3. CPU usage is high, though other apps (Kwin for example) are still responsive. Plasma does not respond though: clicks in for example the task manager (in a panel) are delayed until after the lag, which often results in lots of flashing windows popping up and down once the microblog completed. Also, the clock in my panel, updating every second, simply stops moving until after the lag (when it'll make a jump). All in all, this makes the desktop pretty unusable. I haven't exactly timed it, but on my Athlon64 5200+ (dual core) plasma seems to lag for about 1 minute or so. It does indeed seem to become more noticable once the session is open for longer, though I'm not exactly sure about that. Also, I cannot confirm that it happens before or after loading/showing the items; though I could check. Plasma-workspace package is compiled with python, xcomposite and xinerama support. Plasma-addons has the semantic-desktop (nepomuk) use flag enabled, though I'm not sure if that matters anything for the microblog plasmoid. In my ~/.kde/tmp-[user] directory I'm also seeing lots of temporary files "plasma-desktop[a-zA-Z]xxxxx.tmp" (where xxxxx seems to be the pid(?), there are multiple files for each pid). Their contents are either: --- [invokeAction] actionId= --- Or --- [auth] password= [update] password= status= --- And a few are completely empty. I'm not sure if these files have anything to do with this issue? Using Gentoo AMD64, Qt 4.5 (though I saw it with KDE 4.2.3/Qt 4.4.3 too), nVidia 9600GT with 180.51 nVidia binary drivers. Compositing is enabled (OpenGL). Hope this helps!
Created attachment 34173 [details] limit running http process the point is that too many kio_http process are created (bug 192625) that i think it's soething thaqt should be kio itself to control.. the attached patch seems to somewhat mitigate the issue (i don't get many freezes now) i'm hesitant on that because is not really the proper place for the fix tough
yes, it is the wrong place, but let's put it in with a bit FIXME comment there with a reference to bug 192625, and maybe add a comment on 192625 that when it's fixed to notify plasma-devel so we can undo this...
SVN commit 976814 by mart: explicitly limit the number of http connection here, but this is just a temporaty workaround to bug 192625, to be reverted as soon as it's fixed. BUG: 194345 CCBUG: 192625 M +22 -6 imagesource.cpp M +2 -0 imagesource.h WebSVN link: http://websvn.kde.org/?view=rev&revision=976814