GNOME Bugzilla – Bug 170600
gtk_tree_view_set_cursor really slow after presize but before validate_rows
Last modified: 2005-07-09 16:19:00 UTC
All of the planets need to be aligned to experience this bug, but it's pretty bad and I think it is worth fixing. The motivation for this bug is an application which selects the item under the mouse cursor. This is used in eclipse to create lists that look like menus, where the item under the mouse cursor is highlighted. When a window with one of these lists opens in eclipse, the selection brutally lags behind the mouse cursor until the user stops and waits for it to catch up. Once all of the idle handlers have run, the selection tracks the mouse perfectly. Here are the specific steps: 1. Create a tree view, add lots of items 2. Change the style, or set the size request, ... Do something that causes tree_view->priv->mark_rows_col_dirty to become TRUE. This installs the presize handler. 4. Note that at this point, gtk_tree_view_set_cursor() is fast. 5. When the presize handler runs, it will now mark the root node in the tree as being GTK_RBNODE_DESCENDANTS_INVALID. 6. At this point, gtk_tree_view_set_cursor() is slow. 7. Stop moving the mouse, let the validate_rows handler run. This validates everyone. 8. At this point, gtk_tree_view_set_cursor() is fast again. The time in gtk_tree_view_set_cursor() is entirely in gtk_tree_view_clamp_node_visible(). What is happening is that every time we set the cursor, we process updates and then queue up a scroll. Handling the expose event is extremely expensive when there is a scroll to do and the tree is not validated.
Created attachment 38803 [details] Test case
The (evil?) fix is to simply validate all of the rows after calling process_updates and scroll_to_cell in clamp_node_visible using: while (validate_rows (tree_view)); Since this solves the problem for me, I think it proves that this is what is causing the trouble. I don't know if this is a good fix for the problem though.
That fix is totally not right. It totally breaks the incremental sizing nature of the TreeView, and will result in operational hangs when setting the model. A better fix would be to be to check to see if the area we want to scroll to is valid instead of just assuming if there are any invalid rows. That will fix this particular problem.
I committed the following patch to CVS HEAD, which fixes the problem shown in the testcase here. Does this work for you?
Created attachment 48016 [details] [review] committed change.