Re: Treeview rendering slowness

[Greg Breland <gbreland mozillanews org>]

On Tue, 2004-01-13 at 00:00, z2274394 student unsw edu au wrote:
> Hello all,
>
> I am new to GTK. I got a GtkTreeView(list) with 15 columns and 16000 rows
> storing doubles. It is very slow at startup but at least it works. 

I haven't implemented grids in my project yet, but I did a quick test
before choosing GTK with 65,000 rows artificially generated in a for
loop and it rendered in around 2 seconds on my 2GHZ AMD system.  I
haven't ever used grids of this size in any other toolkits, are GTK
grids slow?  How fast would Win32 render a 16,000 row grid?  From what I
have seen with ~500 row grids on Win32, I think pretty slow, but I am
probably completely wrong because the below post to GTK-devel on Dec
17th seems to indicate that grid rendering will get much faster in the
next version of GTK.  

The change is a pretty fundamental optimization in that it assumes that
all rows will be the same height.  I would be amazed if the intrinsic
Win32 grid can even have variable row heights and therefore probably
faster than existing GTK grids.  GTK grids are very flexible and I would
not be surprised if they are a bit slow.  However, this flexibility is
why I choose GTK for my project.  I don't know of any other Grid where I
can change the font/background color of individual rows.

        I just committed /the/ fixed height patch for GtkTreeView to
        GTK+ HEAD.A fixed height GtkTreeView basically means that we
        only measure the height of the first row and use this height for
        each row in the GtkTreeView. The default GtkTreeView behavior is
        to measure the height of each row (though it is done in an idle
        handler), for GtkTreeViews displaying big datasets this takes a
        loooong time.
        
        Our advise is to only enable this feature in case it could be
        useful. For GtkTreeViews showing large datasets, where all rows
        basically have the same height, it will be very very useful to
        enable. The speed increase is significant. We are very afraid of
        people enabling this on each and every GtkTreeView. This is not
        useful. Please do not do that.

> It uses
> multiple selection and when user selects rows, it runs a callback function. The
> callback function runs a for loop on all rows selected and is quite slow when
> more than 1000 rows are highlighted. The problem is not the slowness of the
> callback, but the treeview widget doesnt render itself with the selection
> proberly. ie, pressing ctrl-A and have to wait 10 sec to see that it is all
> highlighted. I think the treeview widget redraws itself after finishing the
> callback.
>
> Is there a way to do the drawing first (ie show what the user have selected)
> then run the callback function in the background, with preferably a progress bar
> etc.

This is just a vague suggestion from a dream like flashback of reading
the GTK manual, but can't you specify that callbacks happen either
before or after a given event?  Seems like the default is before so you
can pass True or False from your callback to stop the event from falling
through to the default behavior like drawing the selection of the row
clicked.