Re: ideas on improving the performance of gtk_tree_view

[Nicolas Setton <setton adacore com>]

[Thanks everyone for your answers]

> There is a really simple answer to this: GtkTreeView is not a table,
> it was not designed to handle views like this with >> 50 columns.

I'm not sure I understand this part: should I use a gtk_table to  
display this kind of data? What is the preferred way to display this  
kind of information (5000 columns x 50 rows) in Gtk+? The GtkTreeView  
seemed the best approach to me.

Moreover, the GtkTreeView 'almost' supports this, so I think it would  
be a shame to simply throw down our weapons so soon! See below for  
suggestions.

> That would only help GtkListStore, other models might need different
> solutions.  There are also multiple places in GtkTreeView which all
> assume a reasonable amount of columns (I would say < 50), I am not  
> sure
> if all this is worth changing at all.

The GtkTreeStore would also benefit from that, but I agree with you,  
it might not be worth changing.

> > I'm not familiar with this area yet, so I'm puzzled: is the call to
> > gtk_tree_view_column_cell_set_cell_data really needed for the
> > purposes of gtk_tree_view_bin_expose, or is it just needed for the
> > call to gtk_tree_view_has_special_cell?
>
> It is needed to make the call to gtk_tree_view_has_special_cell()  
> return
> a proper and correct result.  This correct result is required in order
> to make the key navigation behave properly.

This gives me an idea.

Proposal (1): we give the user the possibility (through a property,  
for instance) to deactivate keyboard navigation, in exchange for an  
enormous gain of performance for big trees.

> > In any case, I suggest we cache this - probably there is no need to
> > do it in every expose call, only after the model data has changed.
>
> This is something which cannot really be cached, CellDataFuncs can  
> also
> influence this value, and CellDataFuncs can depend on more data than
> just the data found in the model.

This gives me another idea, which I think is better than Proposal (1).

Proposal (2): we give the user the possibility to tell the tree view  
that the only way the data will change is through the model. When the  
tree view is guaranteed this, it executes the loop on  
gtk_tree_view_column_cell_set_cell_data only once in each model  
change, and not once in every expose.

Note that, when you deactivate this loop, you get very fluid response  
even for the 5000 columns tree. We're looking at something like 5000%  
performance increase, and this the kind of users would get from  
Proposal (1) or Proposal (2).

What do you think?

Nicolas