Re: GtkCList & GtkScrolledWindow

[Havoc Pennington <hp redhat com>]

"Charlie Schmidt" <ishamael themes org> writes: 
> im not a big fan of GtkCList, it takes a long long time to insert a lot
> of rows, but i suppose its all we have, right?

It's actually pretty fast, i.e. it's not doing a lot of work
per-row. It's just that this operation is inherently O(n). You aren't
going to get it to scale beyond that.
 
> this way (at least, in my mind) i could insert the first 20 or so rows
> that would be required for display, and set the scroll bar so it looks
> like there are however many inserted, and then thread an insert function
> to append the rest of the rows.
> 
> or, alternatively, can anyone tell me that the new GtkTreeView widget is
> significantly better for inserting, say, 10000-50000 rows all at once? 
> ive tested it a bit in Gtk+-1.3.6, and wasnt very impressed (in fact, it
> seemed much much slower than GtkCList even).
> 

It is much slower than the CList. However, there are two things we can
do.

a) You can write a custom model. So if you already have your row data,
you don't actually need to "insert" it. The only issue is how long it 
takes GtkTreeView to compute the display.

b) For computing the display, we can do it incrementally as for
GtkTextView. Try putting a lot of text in the text view to see how it
works. Basically you compute the onscreen display first and go ahead
and show it, and do the rest in the background. Web browsers do this
same thing as data streams in.

Those two things should remove the O(n) issue, getting stuff onscreen
becomes constant-time-ish.

Havoc