Re: GtkTreeView : why so many "refresh"

[Havoc Pennington <hp redhat com>]

On Tue, Aug 12, 2003 at 10:54:07AM +0200, Francois MARTIN wrote: 
> In fact, I don't see why the treeview needs to refresh its whole view
> when one of its row has been changed, especially as there is no
> auto-sort of the lines nor auto-resize of the columns, and if the size
> (especially the height) of the cells does not change.
> Can you explain me what those calls are intended to do, and why the
> refresh of the changed row, and only of this one, is not enough ?
> Is there a way to curb the treeview to refresh/access data only for the
> refreshed row and not to all visible lines of the treeview.

Oh, I see what you're asking. I think it just doesn't bother to
optimize that. If it's a speed problem for your app maybe you could 
go into gtktreeview.c and figure out how to optimize it.

> It is exacly what I did !
> More over, using an unique 'my_cell_data_func()', I have to distinguish
> which cell (i.e., which column) I supposed to render. To do that, I
> identify
> columns with an id set into their "user-data" property and retreived by
> g_object_get_property(column, "user-data", &gvalue_of_type_pointer);
> By gprof'ing my program, this access appears in the top ten of the most
> cpu eater functions. Is there another quicker way to set and get a client
> data into a GtkTreeViewColumn in order to identify it ?

Surely there is, but I don't know offhand what the best way would be.

> But, it is a bit cpu intensive to do that just when the mouse
> pointer is simply hovering over a cell, without selecting it !  Is
> there a way to deactivate/ignore the "prelit" status without
> overriding my own cell renderer ?

Not that I know of.

> > Note that you can also stuff all your data into one of the prebuilt
> > models such as GtkListStore, rather than using a cell_data_func();
> > that would give the behavior you're asking for.
>
> I am quite sure all those access are still done, even if we don't see
> them since there are "internal".

Well sure, but they aren't visibly slow on GtkListStore.

Havoc