[make LargeLists standard]
sounds good to me!



> Here are the causes of the slowdown as I understand (LargeLists mostly
> addresses these, I believe)
> 1) Lists are slow to create and populate because the StringMorphs are
> created all at once. This can be alleviated by creating them lazily (which
> is a bit tricky afaik). LargeLists does this. This is the more minor problem
> imo, but still annoying if, for example, you want to open a list of 5000
> email messages.

LargeLists doesn't even use StringMorph's, actually.  It has a
"LazyListMorph" which knows how to display a long list of strings,
taking into account the clipping rectangle.

Also, there's another cost that LargeLists takes care of: it can take a
long time to compute the strings from the domain items.  For example, in
Celeste, if you are viewing a list of 10000 email messages, then in a
regular list morph that's 10000 summary lines that have to be computed
up front.  If only 10 of those will be displayed at a time, this is a
big waste.  To take advantage of this second possibility, you have to
use an extended interface to the list morph,however; the standard
interface requests all items at once through the #getListSelector.


As for scrolling speed, note that it is  hard for ScrollPane to do
better.  The root problem is that the submorphs ivar is a simple Array;
a fancier data structure is necessary.  Also, it may be best to stick it
all the way up in Morph; it's not ScrollPane only that deals with
clipping panes.  Furthermore, note that the better data structure is
useful for forwarding mouse events to the correct submorph, as well.


Lex