Thanks very much indeed for this pointer, armed with
this info I've speeded up the loading of my grids by a factor of 5.
I had been trying:
TreeViewColumn::set_fixed_width()
and
TreeViewColumn::set_sizing(TREE_VIEW_COLUMN_FIXED)
but hadn't noticed CellRenderer::set_fixed_size(width,
welcome.
John
Igor Gorbounov wrote:
Gtk::TreeView performance
Hi, All!
My application uses a TreeView (using ListStore model)
table to present
measured data
once per second. This table has about 20 rows and
about 40 columns.
The problem is in consuming too much CPU
John Gill wrote:
[]
My suspicion is that the treeview is calculating the layout of the
renderers within the the fixed width of each column. I'm guessing if
there was an option to stop it doing this (since its initial layout is
more than good enough for me) that we would see a dramatic
Igor Gorbounov wrote:
John Gill wrote:
[]
My suspicion is that the treeview is calculating the layout of the
renderers within the the fixed width of each column. I'm guessing
if there was an option to stop it doing this (since its initial
layout is more than good enough for me) that we
David Jensen wrote:
[...]
try keeping a Glist of structs of GDK::Colors that matches the ListStore
row:column 'color' cells. Have the row:column colors be pointers into
the Glist.
accessing a Glist struct is cheap, accessing a row:column is very
expensive
i'm afraid that i don't quite
Igor Gorbounov wrote:
David Jensen wrote:
try keeping a Glist of structs of GDK::Colors that matches the
ListStore
row:column 'color' cells. Have the row:column colors be pointers into
the Glist.
accessing a Glist struct is cheap, accessing a row:column is very
expensive
i'm afraid that
Igor Gorbounov wrote:
Hi, All!
My application uses a TreeView (using ListStore model) table to present
measured data
once per second. This table has about 20 rows and about 40 columns.
The problem is in consuming too much CPU resources (about 14% when the
table is
switched on, and near 3% when
Hi, All!
My application uses a TreeView (using ListStore model) table to present
measured data
once per second. This table has about 20 rows and about 40 columns.
The problem is in consuming too much CPU resources (about 14% when the
table is
switched on, and near 3% when it is switched off).
