Re: [gtk-list] GtkClist speed problem
- From: Jay Painter <jpaint serv net>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] GtkClist speed problem
- Date: Thu, 4 Jun 1998 14:36:28 -0700 (PDT)
> I have a problem using GtkCList in a program that may need
> very long lists (I can imagine 10000 or higher). The only way
Good UI design would dictate you avoid a situation where you have more
than a couple of thousand rows. The interface becomes unusable when you
have so many rows.
> I have found to select and unselect rows is by calling the
> gtk_clist_(un)select_row routines ; when I have to select
> a high number of rows, the program slows down very much. I do
> not forget to call gtk_clist_freeze before starting selections.
> For example, on my DX4-100, selecting 6000 rows on a 7000 items
> list takes about 5 minutes.
I'm not surprised -- selecting a row requires a linked list traversal, a
screen update if the row is visible, and a signal emittion.
> So, I took a look in the code (I use version 1.0.3). I tried
> to modify directly the selection list before calling
The selection list doesn't have anything to do with the selection state of
a row -- the selection list is synced with the selection status of rows as
a convience to the user of clist.
> gtk_clist_thaw, but that gave no effect :-(. Does it exist
> something to set by a few calls (or even one :-) all the
> elements of the list that must be selected ? I think about
> something like : gtk_clist_select_rows(GtkCList *cl, GList *sel),
> sel a GList of rows numbers for example.
If you really needed to select so many rows, you'll have to 1)freeze the
list 2) get the clist->row_list and change the rows you want to selected
3) add the row #'s of the rows you selected to the selection list. This
would be pretty fast, as long as you cached the end of the selection list
for appending, but you wouldn't be sending out any row_select signals.
] [Thread Prev