gtkroomlist responsiveness

[Gabriel Schulhof]

On Sun, 2008-01-06 at 07:18 -0800, Sean Egan wrote:
> On Jan 6, 2008 5:46 AM, Gabriel Schulhof <nix at go-nix.ca> wrote:
> > The use of while(g_main_context_iteration(NULL, FALSE)); as in the patch
> > below makes gtkroomlist much more responsive (read: usable) on slow
> > processors (such as the OMAP 2420 used in certain Internet
> > tablets ;o) ), and doesn't seem to cause any adverse effects on the
> > desktop:
> 
> I don't recall the specifics, but I remember we've had to remove
> g_main_context_iteration() calls from Pidgin in the past as it had
> some thread reentrancy problems against dbus or gstreamer or some
> such. Is it possible to use g_idle_add here instead, which does not
> have the same problems?

Aha, OK. Is this still the case? What about gtk_main_iteration_do()? Is
that also dangerous?

The reason I hesitate to resort to idle calls is that I'd be inserting a
ton of them - one for each chat room. I don't know if the g_idle
mechanism can efficiently handle so many idle calls. There's also the
matter of allocating a structure of the form

struct _AddRoomIdleParams{
  PurpleRoomlist *list;
  PurpleRoomlistRoom *room;
};

for each idle call, to be passed as a parameter to the idle function,
because it can't take two parameters. As many of these would have to be
allocated as there are chat rooms, and freed at the end of the idle
call's execution. I suppose it's worth an experiment ...

I also thought about bunching up the chat rooms and adding one idle call
for each bunch, but there's no good way to really do that, because the
size of the bunches would be completely arbitrary, and I don't think
even knowing the total number of chat rooms would help, because I can't
think of a good heuristic for determining a bunch size that would keep
the UI usable when added "atomically".



Gabriel