Open fsateler opened 9 years ago
Here is some context of this issue:
17:14:24fsateler: the issue is Smuxi does fetches the backlog in a background thread 17:14:36 fsateler: but pushes ALL messages in a single loop into the UI 17:14:40 fsateler: and that is the UI hang you see 17:14:51 and yes GTK is that slow ;) 17:15:41 so the symptom is like "hey Smuxi hangs, but this is easy to fix!" not quite 17:19:17 meebey: OK I see 17:19:28 fsateler: but it is an issue that should be fixed, no doubt 17:19:38 fsateler: it is just that it depends on user behavior/settings 17:19:45 fsateler: regular values do not cause harm :) 17:19:49 meebey: can you hint me where should I be looking (source) to find that loop? 17:19:57 sure, hold on 17:21:09 fsateler: https://github.com/meebey/smuxi/blob/master/src/Frontend-GNOME/Views/Chats/ChatView.cs#L563 17:21:34 that loop needs to process the list in chunks 17:21:40 like 100 messages per iteration 17:21:55 it can use an anonymous method/lambda expression 17:22:04 GTK has an idle loop for this 17:22:18 so it would call it when GTK has time 17:22:23 as in no UI hang 17:22:37 example https://github.com/meebey/smuxi/blob/master/src/Frontend-GNOME/Views/Chats/ChatView.cs#L462 17:23:01 the return false means it does not want to be called again 17:23:14 if you return true, it will call the callback again
I recently expanded the amount of buffer lines to keep on the server, and noticed that now the extra data to fetch results in the UI becoming unresponsive while the data is being loaded.
I am not sure if the problem is lock while fetching data or while building the UI. May be the latter since CPU usage tends to spike after a successful connection to the server.
Smuxi version 0.11 on both windows and linux exhibit this behavior. The server I'm using is version 0.8.10 on debian wheezy.