Re: simplelist speed

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

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