Bug 181015 - When I have not internet connection, plasmoid web browser makes plasma slow during the startup of kde
Summary: When I have not internet connection, plasmoid web browser makes plasma slow d...
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Andrew Stromme
URL:
Keywords: triaged
: 195227 199927 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-16 21:52 UTC by Mathieu Tournier
Modified: 2009-11-24 23:55 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Tournier 2009-01-16 21:52:14 UTC
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
Comment 1 Dario Andres 2009-01-17 01:20:17 UTC
This may be related to bug 173316 and bug 170769
Comment 2 Anselmo L. S. Melo (anselmolsm) 2009-04-25 21:25:18 UTC
Works for me: I can't reproduce it on trunk r958853.
Comment 3 David Palacio 2009-06-06 06:31:06 UTC
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.
Comment 4 Dario Andres 2009-06-07 15:42:34 UTC
@David: what is your KDE version?
Has anyone tried with a recent KDE ?
Thanks
Comment 5 David Palacio 2009-06-07 16:48:17 UTC
> @David: what is your KDE version?
> Has anyone tried with a recent KDE ?
> Thanks

KDE svn trunk/, built some day this week.
Comment 6 Aaron J. Seigo 2009-06-09 00:58:46 UTC
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)
Comment 7 David Palacio 2009-06-09 02:30:42 UTC
(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.
Comment 8 Aaron J. Seigo 2009-06-09 03:10:50 UTC
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! :)
Comment 9 Aaron J. Seigo 2009-06-10 08:30:19 UTC
*** Bug 195227 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Stromme 2009-06-14 01:48:16 UTC
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.
Comment 11 Andrew Stromme 2009-11-24 23:42:34 UTC
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
Comment 12 Andrew Stromme 2009-11-24 23:55:46 UTC
*** Bug 199927 has been marked as a duplicate of this bug. ***