Re: GtkTreeView very slow for large lists

[John Lindgren <john lindgren aol com>]

On 12/15/2011 09:56 PM, Steve . wrote:
> John,
>
> I can't tell you this /will work/. More over this is how I'd first
> approach the problem (maybe I'm way off base here too)
>
> My initial thoughts are that the user can't see 100,000 items at once
> so there is no need to expect the widget to handle such a large list.
> Instead, I abstract and say we have two lists. The first list the user
> can see, this is the view port. It is small and snappy. The second
> list is the complete list, if the complete list were to be rendered by
> the widget it would painfully sluggish due to its size.
>
> The view port is just what it suggests, it is a view port in to the
> main list. The view port has a given delta, which is the amount of
> items that can be viewed on the screen minus the total view port
> count. Using this delta we can update the view port from the main list
> as the user navigates through the list. It's always one step ahead of
> the user.
> By updating the small, but fast view port with items from the larger
> complete list the UI remains quite snappy. The down side is that it
> may require some major architecture modifications depending how the
> lists are stored / referenced. Not to mention maintenance headaches

Shouldn't GtkTreeView already be doing this, or something like?  As a
matter of fact, I wrote/rewrote a custom list widget for Audacious's
older WinAmp-style interface that is much better at handling long lists
than GtkTreeView, because instead of calculating the dimensions of every
single item in the list, it only looks at the ones actually displayed.

> You had mentioned some test code somewhere?  You've got me curious as
> to how some of the older machines would perform here. Where is this
> test source, is too large to provide verbatim copy here?

I had sent it as an attachment to my first email, but it seems this list
doesn't allow attachments.  Here is a link: http://pastebin.com/45br5X3Z

-- John