Re: simplelist speed



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]