Re: I found the bottleneck, please tell me how to fix it...

[Gus Koppel <gtk spamkiller bytechase cx>]

Maurizio Colucci wrote:

> For http://segusoland.sourceforge.net , I have found the bottleneck in
> my ListBox widget. I have a ListBox, implemented with
>
> ScrolledWindow
>   Viewport
>      VBox
>         EventBox
>         ...
> There are about 2000 EventBoxes in the VBox. Each time an EventBox is
> clicked, it hides itself. The problem is that hiding the Nth EventBox
> sends on_size_allocate messages to EventBoxes {N+1, ..., 2000}. Yes,
> not to all of them: just to the EventBoxes that follow the hidden one!
>
> So if I click the _last_ EventBox, the update is instantaneous. If I
> click the _first_ one, it is slow as hell.
>
> I need a way to avoid sending those on_size_allocate messages to the
> EventBoxes at all. The messages are useless anyway, because no resize
> is taking place! This must be possible... please help me!
>
> I tried putting gtk_widget_freeze_child_notify in position (*) and
> gtk_widget_thaw_child_notify in position (**), but it won't
> work... (and I couldn't find good info about what these functions
> really do).

After looking to the screenshots of your program it isn't clear to me
why you try to implement your own listbox with thousands of eventboxes
in it. I think the same appearance and likely the same behaviour (though
I don't know about the behaviour of your listbox) can be achieved by
using GtkTreeViews with a GtkListStore model, can't it? While
GtkTreeViews with thousands of entries are necessarily a bit slow I
think they would be significantly faster (and less resource consumptive)
than using thousands of eventboxes (widgets at all) in a window.

The hard way to accelerate things (even more than with a GtkTreeView)
would be to create an own, optimized listbox style widget which is able
to manage rows, cursor and moving via keyboard on your own. I think the
standard GTK treeview and its models are aimed more towards flexibility
than high performance with very long lists. You might need just the
opposite (as some others do, I think).

A custom list widget would provide you with maximum performance (much
less GTK calls needed) and full control over the behaviour of such a
widget. VBoxes and EventBoxes wouldn't be needed (just a ScrolledWindow
and a Viewport). However, it would be more long winded to implement.

Anyway, using thousands of EventBoxes in a list-style widget seems to me
the most inefficient strategy, even without your particular messages
issue.