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

On Thursday 15 January 2004 08:00 am, Gus Koppel wrote:


Thank you so much. I understand I have not been clear at all.

I have been mixing the terms "selection/deselection" and "hiding"
because in my application they are almost the same thing: each time
you select an item, MANY other items are hidden. This is called
narrowing an is the most important feature in my app. Sorry if this
seemed silly.

What I really need is a way to hide an item in nearly constant time
(see further).

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

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? 

No, sorry. I mean, as you later assumed, a time that does not depend
on the number of items. :-) technically referred to as O(1).

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. 

Yes, that is why I said that it would be acceptable O(N), i.e. hiding
an item in a time that only depends on the ACTUALLY VISIBLE
items. These are NOT the items for whic is_visible() returns true!
is_visible() returns true for 2000 items, but there are only about 10
items not clipped away, outside the viewport.

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.

   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

Yes, but the widget could keep two lists internally: one with the
actually visible items (about 10), one with the current visible items
(about 2000), and it would be solved...

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?

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 know, I seemed to be contradictory. I eaxplained above that hiding
is a consequence of selection/deselection.

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.

Please tell me if the solution I proposed (keeping two lists) seems
feasible to you.

Thank you very much


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]