Ubuntu
software-center package

Software list views with variable-height rows scroll slowly

Bug #524567 reported by Matthew Paul Thomas on 2010-02-19

This bug affects 3 people

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://people.canonical.com/~mvo/tmp/Screenshot-Ubuntu%20Software%20Center.png> It doesn't look as good, but more importantly, it wouldn't scale to adding a "Choose Add-Ons…" button to the row later. And if we solved the problem a different way later, we would have inflicted on users three different layouts in three successive versions of Ubuntu Software Center.

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://wiki.ubuntu.com/SoftwareCenter#get-software-list-view>

* 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://code.launchpad.net/~mmcg069/software-center/fastappview-kinda-working>, which makes scrolling noticably faster, though I don't know how.

(This is not the same as bug 460366, which was apparently happening even for 1.0.)

See original description

Matthew Paul Thomas (mpt) on 2010-02-19

description:

updated

Revision history for this message

Cody Russell (bratsche) wrote on 2010-02-19:

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.

Revision history for this message

Cody Russell (bratsche) wrote on 2010-02-19:

The way I was thinking this might be implemented is:

When the treeview selection changes, remove the buttons and set fixed-height-mode=true as mpt said, then start a timeout for 0.5s (or however long). Each time the treeview selection changes, reset the timer. Once the timer expires then set fixed-height-mode=false and show the buttons again.

We could possibly do something similar whenever the user grabs a scrollbar, but we need to look into that. There are some potentially relevant signals in GtkWidget, such as "grab-notify" and "grab-broken-event"

Matthew Paul Thomas (mpt) on 2010-03-09

description:

updated

Revision history for this message

Matthew McGowan (mmcg069) wrote on 2010-03-09:

Hi,

I am the author of https://code.launchpad.net/~mmcg069/software-center/fastappview-kinda-working. The important class is in softwarecenter/view/appview.py, the class name is AppView.

My approach is to maintain an internal 'complete list' (AppStore) and a 'visible list' (AppView.vis_list). The visible list only takes from the complete list what is required to satisfy visual needs, i.e. only lookup from the complete list and update the treeview for the AppStore rows that are visible (make sense?). Typically, when USC is maximised, my bona fide gtk.treeview only has to deal with ~20 rows of data at my resolution of 1152x864.

I have this working quite nicely for mouse scrolling and small increments, big drags (drags that move through the list in row-steps > vis_range) are still quite sluggish.

Latency is all but gone on treeview updates. Before a noticable amount of time was spent recalcing the treeview when a row was selected. This treeview churn interrupted pathbar animations, making them jerky. This is mostly gone in my branch even with large lists (200+ rows).

Moreover, my approach according to mvo is faster to load than a traditional treeview. As per a conversation with mvo in irc, in one case wrt USC, we went from 2 secs to 0.4sec to load the treeview. Although i am not sure if this still holds true and not sure what size list produced this result. Regardless this still sounds nice! :)

Obviously my efforts are far from perfect. There are things i dont really understand about the treeview that mean i can't quite get the alignment of rows perfect at the upper extent when using the keypad to iterate through the list.

Things i dont get that are hindering my approach include:

* I dont know how to ungrab a focal row. A double-click emits an activation that (to me) seems a special case. The row focus no longer becomes bound to the selection, i.e. i can unselect_all and yet there remains a focal row. And since my method basically recycles rows, a focus rect is retained for the iter/path activated and is visible when scrolling, despite no row being selected. Creates visual yuckness. Any suggestions on a api call to ungrab a row?

* I dont get how to calc the vadjustment.upper value wrt to the treeview. If the expanded row is visible, my upper val is correct. If the expanded row is not visible, then i display an extra row with junk data. I guess i should be nudging the treeview vadjustment.value in this case to make things look correct?

Hope this makes some sense, any advice greatly appreciated!

Hi,

I am the author of https://code.launchpad.net/~mmcg069/software-center/fastappview-kinda-working.  The important class is in softwarecenter/view/appview.py, the class name is AppView.

My approach is to maintain an internal 'complete list' (AppStore) and a 'visible list' (AppView.vis_list).  The visible list only takes from the complete list what is required to satisfy visual needs, i.e. only lookup from the complete list and update the treeview for the AppStore rows that are visible (make sense?).  Typically, when USC is maximised, my bona fide gtk.treeview only has to deal with ~20 rows of data at my resolution of 1152x864.

I have this working quite nicely for mouse scrolling and small increments, big drags (drags that move through the list in row-steps > vis_range) are still quite sluggish.

Latency is all but gone on treeview updates.  Before a noticable amount of time was spent recalcing the treeview when a row was selected.  This treeview churn interrupted pathbar animations, making them jerky.  This is mostly gone in my branch even with large lists (200+ rows).

Moreover, my approach according to mvo is faster to load than a traditional treeview.  As per a conversation with mvo in irc, in one case wrt USC, we went from 2 secs to 0.4sec to load the treeview.  Although i am not sure if this still holds true and not sure what size list produced this result.  Regardless this still sounds nice! :)

Obviously my efforts are far from perfect.  There are things i dont really understand about the treeview that mean i can't quite get the alignment of rows perfect at the upper extent when using the keypad to iterate through the list.

Things i dont get that are hindering my approach include:

* I dont know how to ungrab a focal row.  A double-click emits an activation that (to me) seems a special case.  The row focus no longer becomes bound to the selection, i.e. i can unselect_all and yet there remains a focal row.  And since my method basically recycles rows, a focus rect is retained for the iter/path activated and is visible when scrolling, despite no row being selected.  Creates visual yuckness.  Any suggestions on a api call to ungrab a row?

* I dont get how to calc the vadjustment.upper value wrt to the treeview.  If the expanded row is visible, my upper val is correct.  If the expanded row is not visible, then i display an extra row with junk data.  I guess i should be nudging the treeview vadjustment.value in this case to make things look correct?

Hope this makes some sense, any advice greatly appreciated!

Revision history for this message

Matthew McGowan (mmcg069) wrote on 2010-03-09:

Woops. I should reread my posts! Amend my last bullet point: ~

* I dont get how to calc the vadjustment.upper value wrt to my vscrollbar. If the expanded row is visible, my upper val is correct. If the expanded row is not visible, then i display an extra row with junk data. I guess i should be nudging the treeview vadjustment.value in this case to make things look correct?

Gary Lasker (gary-lasker) on 2010-03-17

Changed in software-center (Ubuntu):
status:	New → Confirmed

Revision history for this message

zp (zekopeko-deactivatedaccount) wrote on 2010-03-23:

Does this bug cause the lag when you filter/search?

Revision history for this message

Matthew Paul Thomas (mpt) wrote on 2010-09-14:

This is pretty well fixed in Maverick. Thanks to Matthew McGowan for his excellent work.

Changed in software-center (Ubuntu):
status:	Confirmed → Fix Released

Revision history for this message

Esmaeil MIRZAEE (esmaeilmirzaee) wrote on 2011-08-27:

In bug #830258, we got another error like this but it gets worse.
software-center-gtk3 trunk r2155, Ubuntu Ocelot
1. Go to a list view, e.g. the "System" category.
2. Click on a list item near the bottom of the screen.
3. Press the Down key a few times.
What happens: Eventually the selection is not visible, because it is off the bottom of the window.

Revision history for this message

Matthew McGowan (mmcg069) wrote on 2011-08-28: Re: [Bug 524567] Re: Software list views with variable-height rows scroll slowly

Esmaeil, I am not so sure the symptoms you report directly relate to this
bug. The bug you mentioned I believe this is already tracked in a bug
reported by mpt.

On Sat, Aug 27, 2011 at 4:43 PM, Esmaeil MIRZAEE
<email address hidden>wrote:

> In bug #830258, we got another error like this but it gets worse.
> software-center-gtk3 trunk r2155, Ubuntu Ocelot
> 1. Go to a list view, e.g. the "System" category.
> 2. Click on a list item near the bottom of the screen.
> 3. Press the Down key a few times.
> What happens: Eventually the selection is not visible, because it is off
> the bottom of the window.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/524567
>
> Title:
> Software list views with variable-height rows scroll slowly
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/524567/+subscriptions
>

--
From the mind of me!

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.

Ubuntusoftware-center package

Software list views with variable-height rows scroll slowly

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
software-center package