Re: simplelist speed

[muppet <scott asofyet org>]

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.
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.

> 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?


> With Gtk1 Clists, I never saw any delays.
This is also not surprising.  CList was a completely different design, 
not nearly as flexible or extensible, but with built-in support for 
speedy colors.  It also didn't use pango markup, and gtk+ 1.x didn't do 
antialiased text with the RENDER extension (which is the main 
performance bottleneck for gtk+ 2, as i understand).

> I'm guessing that the root of the pointer moving problem is that 
> something is tracking enter and leave events in each cell.  Is that 
> the problem and is there some way to mask those events?
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.

> 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).
--
I bring the rock, and provided it is fiscally responsible, I will bring 
the funk as well.  And that's fo-shizzle.
        -- Saturday Night Live