GNOME Bugzilla – Bug 607447
treeview almost fixed_height mode
Last modified: 2018-02-10 03:44:29 UTC
Created attachment 151758 [details] demo program Hello, I implemented a custom CellRenderer that dynamically grows the current active row to show more information for the selected row. This works nicely but I have to switch off fixed_height mode for this. I would like to be able to still use fixed_height mode because it avoids a lot of the overhead from the validate_row() calls. My view is fixed_height except for the single active row. Attached is a some example python code that illustrates what I did and it includes simple measurements on how long the treeview needs to be fully done (no more events). It runs once with normal mode and once with fixed_height mode. Clicking around in it shows the growing row (and in the case of the fixed-height one the not growing one). I tried to make it as small as possible, it does not contain the custom cell render, its not needed for the illustration (I can provide more code when needed). I attach a simple patch for gtk_tree_view_row_changed() that might be a way to solve the problem by doing a size query on the changed row even when in fixed_height mode and a re-validation of the visible area. If the gtk_widget_queue_draw() in there is a problem it could be solved by only installing the "gdk_threads_add_idle_full (GTK_PRIORITY_RESIZE - 2, presize_handler_callback, tree_view, NULL);" part of the install_presize_handler (). Any other suggestions how to solve this are of course very welcome. Thanks, Michael
Created attachment 151760 [details] [review] possible patch
I did a little bit more testing on this and it turns out that the "queue_draw()" is actually not needed. gtk_tree_view_node_queue_redraw (tree_view, tree, node); seems to be sufficient. I did not measure any noticeable slowdowns when changing it like this when adding lots of rows. Adding 1000 rows takes ~2.4 to 2.5 seconds either way (with or without patched gtk). I will attach a updated demo and a updated patch soon.
Created attachment 156550 [details] [review] updated version of the patch that puts the mode into a special property for testing This adds a "hacked-almost-fixed-height-mode" property that can be used to compare the normal fixed-height and almost-fixed-height mode.
Created attachment 156551 [details] test program that does add/change on the rows I updated the test program to test add/change of the store and see what impact this has on performance. With regular fixed height mode I see times like this: $ python test2.py normal mode (add): 2.47580099106 normal mode (change): 0.184120893478 With hacked-almost-fixed-height mode I see (commented in line 49): normal mode (add): 2.46698594093 normal mode (change): 0.179488897324 Running it multiple times paints the same picture of very similar performance.It could probably be included in fixed_height mode without much ill effect.
What IMHO is the real solution is to get rid of "validation" all together and move from having fully accurate scrollbars to estimate scrollbars. See e.g. https://live.gnome.org/GTK%2B/GtkTreeView/Ideas#No-validation_branch_.28has_patch.29
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.