Version: unknown (using 4.1.96 (KDE 4.1.96 (KDE 4.2 RC1)), Kubuntu packages) Compiler: cc OS: Linux (i686) release 2.6.27-11-generic When I have not internet connection, plasmoid web browser makes plasma slow during the startup of kde
This may be related to bug 173316 and bug 170769
Works for me: I can't reproduce it on trunk r958853.
It happens with the Remember the milk plasmoid too. Even if there is an internet connection, it still slows startup by some seconds, as the connection is not very good/fast.
@David: what is your KDE version? Has anyone tried with a recent KDE ? Thanks
> @David: what is your KDE version? > Has anyone tried with a recent KDE ? > Thanks KDE svn trunk/, built some day this week.
kio is non-blocking, however; are you _sure_ this is a plasma issue? a way to tell is to `kquitapp plasma-desktop`, then start plasma with and without networking. if plasma starts up ~equally quickly in both cases then it's probably something in kio ... ... e.g. kio could be blocking in some dbus call and holding on to some other resource that's also needed by someting else (kded4 comes to mind)
(In reply to comment #6) > kio is non-blocking, however; are you _sure_ this is a plasma issue? > > a way to tell is to `kquitapp plasma-desktop`, then start plasma with and > without networking. if plasma starts up ~equally quickly in both cases then > it's probably something in kio ... > > ... e.g. kio could be blocking in some dbus call and holding on to some other > resource that's also needed by someting else (kded4 comes to mind) Some tests and numbers: - Without networking kquitapp plasma-desktop kshell4 plasma-desktop (plasma starts, but does not render completely [containment(screen 1) with the rtm plasmoid is black]. unresponsive for 40 seconds) (connect network. still unresponsive, but starts drawing containment and applets) (some more seconds, rtm logins and plasma accepts mouse events) - With networking kquitapp plasma-desktop kshell4 plasma-desktop (plasma starts. containment in screen 1 lags a little. rtm plasmoid shows working state (those circles). unresponsive) (rtm logins and plasma accepts mouse events) - With networking (no rtm) 1 second start. both containments draw at the same time. no mouse events blocked. - Without networking (add the rtm plasmoid back) (configure user/pw. ok) (For some seconds plasma is unresponsive to mouse events) Now, what are mouse events? Those include, hover over plasmoids (should appear applet toolbox), hover over taskbar (should highlight task), right click on desktop (should open menu). Nothing of that happens when I say that plasma is unresponsive.
aha! rtm is the culprit! in particular: aseigo@independence:~/kde4/KDE/kdeplasma-addons> grep sendSynchronousRequest libs/rtm/* -r libs/rtm/auth.cpp: QString reply = frobRequest->sendSynchronousRequest(); libs/rtm/auth.cpp: QString reply = tokenRequest->sendSynchronousRequest(); libs/rtm/request.cpp:QByteArray RTM::Request::sendSynchronousRequest() { libs/rtm/request.h: QByteArray sendSynchronousRequest(); libs/rtm/session.cpp: QString reply = tokenRequest.sendSynchronousRequest(); libs/rtm/session.cpp: QString reply = request->sendSynchronousRequest(); libs/rtm/session_p.h: QString reply = settingsRequest.sendSynchronousRequest(); libs/rtm/task.cpp: request->sendSynchronousRequest(); that will freeze the whole application until it returns. not good. p.s. thanks for the follow up and testing. very useful! :)
*** Bug 195227 has been marked as a duplicate of this bug. ***
This requires a rework of some of the librtm internals. I have started this and will complete it when I have time. Thanks for reporting it.
SVN commit 1053872 by astromme: BUG: 181015 Remove the last of synchronous network access from librtm. M +0 -8 request.cpp M +0 -1 request.h M +4 -8 session.cpp M +4 -3 session.h M +13 -5 session_p.h M +0 -12 task.cpp M +0 -2 task.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1053872
*** Bug 199927 has been marked as a duplicate of this bug. ***