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!
> > > [...]
> >
> > 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? 
>
> I discarded GtkTreeViews for two reasons:
>
> 1) I need a list widget capable of hiding and showing items in
>    constant time. I don't see why GtkTreeViews should fulfill this
>    requirement, since it uses a list internally. (But I need to test
>    it.)

If you don't want your list of items being stored in a list then you
can't use VBoxes either. Guess what they use internally?

What do you mean by "constant time"? Periodically? A strict constant
time to add / remove / show / hide items in a listbox(-like) widget
(tree) can never be achieved as you likely know. The number of entries
in the list / being shown always has at least a minor impact on the
timing of display operations, no matter whether you use a standard
GtkTreeView or your own HBox-based construct. In your case the impact
seems to be rather major anyway. Also consider that different computers
have different speeds. So calculating with "constant time" for GUI
operations isn't a good idea at all.

If you actually mean "periodically" instead then there are other, better
options to achieve that, of course.

>    It would be ok if hiding and removing could take O(N), where N is
>    the number of items ACTUALLY VISIBLE (i.e. about ten usually), not
>    the number of items for which is_visible() holds. :-) is_visible()
>    returns true even if the item is outside of the current viewport.
>
>    This would be like achieving constant time, since N is limited:
>    N<20 at worst.

The size of the total list of entries would always have (at least a
minor) impact on timing. Calculating with N == <visible items> only
instead of N == <total number of items oin list> necessarily isn't
precise.

> 2) I need a precise behavior: when the user clicks a deselected item,
>    the item must be selected, and other items must be left
>    untouched. When the user clicks a selected item, the item must be
>    deselected, and the other ones must be left untouched.
>
>    I did some tests and I couldn't reproduce this behavior with
>    GtkTreeViews. This would be GtkSelectionMode =
>    GTK_SELECTION_EXTENDED, but it was deprecated and set equal to
>    GTK_SELECTION_MULTIPLE, which won't do.

Have you tried this?
http://developer.gnome.org/doc/API/2.0/gtk/GtkTreeSelection.html#gtk-tree-selection-set-select-function

Besides, it's not quite clear to me what operation you really intend. At
1. you're speaking about hiding, showing and removing items, in 2. you
speak about selecting and deselecting items. This is not the same. I
think only one of these operations should be performed on clicking on an
item? Anyway, both are possible when using GtkTreeViews.

Anyway, the conclusion remains that if you use thousands of widgets to
represent a list of items it will always be slower to handle than if you
use one widget which is capable of managing multiple (thousands of)
items in a list by itself. Also memory consumption should be much lower
since each widget certainly implies much more overhead than a list entry
inside a GtkTreeView.