Re: simplelist speed

[Dan Espen <dane mk telcordia com>]

muppet <scott asofyet org> writes:
> 
> On Jan 3, 2005, at 9:57 PM, Dan Espen wrote:
> 
> > I needed to color the foreground of individual cells and the 
> > background of some rows.  I used pango markup for the foreground and 
> > cell_data_func to  color the background.
> >
> > On my 400MHz home machine, I can peg the CPU meter by moving the 
> > pointer over the window.  When I switch to the desk that shows 2 
> > instances of this program the text takes about 5 seconds to appear.
> 
> Unfortunately i can't say i'm surprised by this.  The TreeView 
> architecture is flexible and powerful, but the design requires it to do 
> a hell of a lot of work.
> 
> Every time a cell is rendered, the TreeViewColumn must fetch the data 
> from the model and set appropriate properties on the CellRenderer 
> before calling the renderer's render() vfunc.  This is almost a stress 
> test of the GObject property system.
> 
> A way to approach the speed problems is to find ways to cache things.  
> To avoid needing to parse pango markup or call a cell data func on 
> every cell rendering, try using a hidden column (that is, a model 
> column that is not shown in the view) to store the GdkColor to use for 
> the foreground and background colors, and calculate them only once.  
> You'll then tell the TreeViewColumn to use the hidden column as a cell 
> attribute, that is, for a given cell it will fetch the color from the 
> corresponding row of that column of the model.  This would also avoid 
> the need for the cell data func, but would require you to keep the 
> color columns up to date by hand.

I've seen this mentioned, but I couldn't find a sample or detailed
explanation.  Any pointers, hopefully to something in perl?

> SimpleList assumes that all model columns are visible, and keeps the 
> view column and model column indices aligned for simplicity.  To use a 
> hidden column with a SimpleList, you'll have to add them by hand after 
> creation.

My simplelist aleady has 3 hidden columns for input data
that I don't want displayed, I can use them.  I don't have to
add them after creation.  Maybe you mean, I have to add the colors
after creation.

> > If I disable the cell data func, its faster but not by much, maybe 20%.
> 
> What improvement to you see from using text rather than markup columns?

That's not so easy to answer, changing everything to text
crashes the application.  Not sure why...

> I've noticed that in the past, when writing custom cell renderers --- 
> the render vfunc gets called *a* *lot*... whenever you move the mouse, 
> whenever there's an expose, a cell resize, cursor/focus change, etc.
> 
> Peeking at the source (gtk+/gtk/gtktreeview.c) it appears that the 
> point is to support prelighting for cells, e.g., the expander triangles 
> in tree mode.  In theory, this should make it possible to render your 
> control cells (like the check button) with prelighting, but that 
> doesn't appear to happen.
> 
> I suggest logging a bug against gtk+, to find some way to suppress 
> spurious cell repaints.

Yep, I'll try to get more info on how many renders are taking
place first.

> > I'm not sure why the window takes so long to paint on a desk change.  
> > I can see pretty big 100% CPU spikes on desk changes.
> 
> Undoubtedly it's the slow cell rendering, exacerbated by the fact that 
> instead of rendering a handful of cells hit by the pointer motion, 
> you're now rendering every visible cell, as the entire window has 
> gotten an expose event.  I wager you'd see similar behavior when 
> dragging another window in front of your TreeView (assuming you use 
> opaque window moves in your window manager).

Yes, opaque moves over a window are also slow.

-- 
Dan Espen                           E-mail: dane mk telcordia com