[Banshee-List] More ListView Performance Goodness!

["Scott Peterson" <lunchtimemama gmail com>]

As alluded to in an earlier dialog, I've been hacking on a performance
enhancement to Hyena.Data.Gui.ListView scrolling. Currently, whenever
the list is scrolled, all rows are fully rendered. I've roughed out an
optimization which renders each row only when it is revealed by
scrolling. The general way it works is this: the rows are rendered to
an off-screen Pixmap. The pixmap is large enough to fully accommodate
the maximum number of rows visible in the list (which usually means it
is actually larger than the list's Gdk.Window). When the list is
scrolled, it determines whether new row(s) have come into view. Let's
suppose that the list has been scrolled down to reveal a new row on
the bottom. The contents of the Pixmap are then shifted up by the
height of one row and the new row is rendered onto the bottom of the
Pixmap. If you scroll down to reveal two rows, the same process
happens, only everything moves up by two row-heights and the two new
rows come in at the bottom. And so on. The pixels from the Pixmap are
then copied into the on-screen list Gdk.Window, properly offset. But
enough talk, let's see some numbers!

The performance improvement is proportional to how fast you scroll: if
you scroll quickly over a large set, almost no rows will carry over
from one frame to the next so all will have to be rendered and there
will be no performance gain. On the other hand, if you scroll
leisurely, revealing only a row at a time, performance will be
significantly better. I profiled both the optimized and unoptimized
code. Both times I started the program and scrolled through the list
for about a minute, varying the speed of my scrolling, attempting to
behave like a regular user. The relevant number is the average
execution time of the PaintList method. Unoptimized, the avg execution
time is 87ms. Optimized, it is 20ms. So at least we know it works.

There are a few bugs in this patch: there's a slight rendering issue
with column dragging, changing the width of the window screws things
up, and there's a corner case with selection rendering. Those are just
the bugs I ran into at 3 in the morning. There are probably more. I'll
address them and any others when I have another night free (maybe
tomorrow). Until then, I submit this to the list for everyone to a)
look over, b) try out, c) critique, or d) hack on. I've had problems
in the past with sending attachments to the list, so I'll just link to
it: http://homepages.nyu.edu/~stp225/listview-speedy.patch

- Scott