when getting an incoming message and clicking the icon in the tray it takes >1 second to actually display the appropriate chat window. this is 1 second too long and always makes me feel like it is not working Reproducible: Always
We actually don't use overlay, it's "mail-unread-new" icon. We could probably try loading the icon ourselves at defined size and then use KSNI::setIconByPixmap(..). But that would also require some adjustments on panel size changes events.
Oops, wrong bug, sorry :)
What we could do here is a nasty hack... Let the approver pre-load the text-ui right after showing the notification. This kind-of violates telepathy's architecture, but I think it's ok to do it, as there is realistically no other possible handler.
No to nasty hacks just now, there's still a lot we can do, and a lot of research to be done. George K did a valgrind analysis, result was main delays are in parts we can't change. I think the blame is in the factories, it's a lot of dbus calls and won't show in valgrind. We've seen already in the CL reducing these and later calling upgradeContacts() makes a big difference. We can also start loading the HTML themes once the app is waiting for the channel rather than after. There's a static call to load the themes, that we could just move to main() or something. It's a lot of IO. I want: - kDebug() << QTime().mSecsTo(QTime::currentTime()) << "starting XYZ"; littered throughout the code, when every pendingOperation starts and finished and whilst waiting for the QWebView, between main and handle channels. Maybe give it a differnet ID so we can turn it on/off independently. (timing style is taken from plasma, if anyone knows of anything better please say. Can't really use QBenchmark we depend on interaction with other apps too much) - a bustle-dbus-monitor recording of this app starting up (that opens in bustle..mine keeps crashing). so we know how much is plasma, the approver, MC, dbus and actually the text-ui. Martin, you see this issue most. If I add the debug can you run it? (or you apachelogger) We can't act on anything until we know where we're fixing it and why.
(In reply to comment #4) > Martin, you see this issue most. If I add the debug can you run it? (or you > apachelogger) Certainly.
Ok - for the second part I want, could you: close all text chats bustle-dbus-monitor > somefile start a chat. stop the logging, and upload the file.
Created attachment 72546 [details] opening an entirely new chat
Created attachment 72547 [details] getting a reply, clicking the KSNI
Any news on this bug ? It's the main annoying thing I experience with telepathy, and it make me turn back to kopete...
To me this seems better on KDE 4.10, can you confirm what you are running?
I'm running kde 4.10 on arch linux , amd64. While better than previous versions, the delay is still there, and it measured in seconds (more than one). It's very annoying also because I don't get any visual indication that the request to open the dialog window is accepted and going along.
(In reply to comment #11) > It's very annoying also because I don't get any visual indication that the > request to open the dialog window is accepted and going along. Agreed. A lot of annoyance could be saved by displaying *something*. Maybe a spinner icon in the quickchat (if the user uses it), would be a start.
*** Bug 319945 has been marked as a duplicate of this bug. ***
Git commit 828fca048a57aa95f5281aeeae11716469f01c95 by David Edmundson. Committed on 09/07/2013 at 11:53. Pushed by davidedmundson into branch 'master'. Remove FeatureRoster from ConnectionFeatures Now that GlobalContactManager will upgrade the connection object when we request a full contact roster (in the "invite contact" dialog) we don't need to fetch the whole roster on load. (see http://commits.kde.org/telepathy-common-internals/9cc7ea57c830d345bab5377208058fb47b428b69) This should result in faster load times. M +0 -1 app/main.cpp http://commits.kde.org/telepathy-text-ui/828fca048a57aa95f5281aeeae11716469f01c95
Can people please test master and report back if they think it is faster / fast enough. If so I might backport the two changes in 0.6
It does seem slightly faster, still ~1 second delay before anything happens on cold start.
We have added yet more speed boosts into 0.7. Closing