Software list views with variable-height rows scroll slowly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
software-center (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Ubuntu Software Center 1.1.12, Ubuntu Lucid
1. From the main "Get Software" screen, search for "a".
2. With the arrow keys, scroll through the search results.
What happens: The scrolling is rather slow. There's a lot of flashing of "More Info" and "Install" buttons, visually trailing behind the highlighting of the selected item.
This is because the GTK treeview control has an "equal-height" mode, where scrolling is fast for many items; and a non-equal-height mode, where scrolling is slow for many items, but the height of rows can vary. In stock GTK, you can't have both varying height and fast scrolling at the same time, which is what we want.
Michael Vogt has a patch to GTK that would (iirc) allow the selected item to change height even in equal-height mode. But it would make the normal case of non-expanding rows slightly slower, so GTK upstream is unwilling to accept it.
Separately, Michael McGowan has a patch that would make the software list view equal-height. <http://
A third possibility is to copy, embed, and tweak the GTK treeview code inside USC, like Banshee reportedly does. This would be a lot of work.
This morning I had a hare-brained idea about solving this another way, and Cody Russell says it could work:
* At rest, make the treeview non-equal-height, with the selected row larger as shown in the spec.
<https:/
* The moment the user starts scrolling with the keyboard:
1. Remove the buttons from the selected row.
2. Set equal-height on the treeview.
3. Scroll as normal, *without* adding/removing buttons in each row as you zip past it.
* When the user has not been scrolling with the keyboard for, say, 0.5 seconds:
1. Unset equal-height on the treeview.
2. Enlarge the selected row and add the appropriate buttons.
This might even look better than any of the other approaches, because there wouldn't be so much flashing from buttons being added and then removed a moment later.
For a fifth option, see <https:/
(This is not the same as bug 460366, which was apparently happening even for 1.0.)
description: | updated |
description: | updated |
Changed in software-center (Ubuntu): | |
status: | New → Confirmed |
I thought of a situation where this does not benefit us, and that's the case where the user grabs the scrollbar handle and tries to rapidly scroll through the treeview list. The treeview would not be in fixed-height-mode at that point, and scrolling would be rather slow again. Perhaps this can be worked around similarly, but I just wanted to document it here.