Gtk_Tree_View, drawing speed



Dear all,

as you might remember from my questions before, I have an application where I use a tree-view to display some 
data from an external hardware.
At the moment the Data are fetched, displayed and the data for the next row in the tree view are fetched.

For example, if I have 12 Objects in my Treeview 12 times different data are fetched from the external 
hardware and displayed.
In that case I can see that I get a request rate about 400 requests per second.

But this is just If I use flat objects. If I use Objects which have childs in the treeview, then the Update 
rate goes rapidly down.
For example I have a structured object that also fetches Data and displays them on 12 rows, the update rate 
is going down to below 100.
But in fact the effective number updated rows has not changed compared to that case where I have 12 Single 
Objects.
If I collapse some child's in the tree view, I can see the update rate increasing.
To give you an better understanding how this application looks like, you can find a screenshot here 
http://www.pagelnet.de/uctools/a00007.html.

I followed this issue down to that point that I can definitely say that the gtk_tree_store_set() function 
causes the delays.

My assumption is, that if a row has children, some recursive things are done, maybe every time I update one 
item the whole hierarchy gets updated etc.
To accelerate the speed again, I see following options (of course just if my assumption is somehow correct)

1.)
To implement a kind of shadow storage, und just if the data are different to perform the actual 
gtk_tree_store_set() operation.
But I would not prefer this method, it is either not so easy to implement nor is it solving the root cause.

2.)
To find a way, to synchronize the invoked cell renderes, so that I just make one drawing update after I set 
the last Item.
For example, I can try to use just one tree_store_set operation per hierarchy (now i have one tree_store_set 
operation per row),
but also for this I have to create a kind of shadow memory.

3.)
Implement a own cell-renderer, which can do above things.

Do you see any other option?

regards
  Arne.











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