Ned,
Oops, that didn't come out right. Your example would work as advertised. The
code in
TransformMorph>>localVisibleSubmorphBounds

has the fairly useless
   self submorphsDo: [:m |  (m visible) ifTrue: [ bleh ]

which is what I was thinking about. Of course, a per-morph operation is
still involved either way.

Sorry.
Eddie

PS. For the browser benchmark, maybe you mean this?

saveMorphs _ self currentWorld submorphs.
self currentWorld removeAllMorphs.  "heh, heh"
time _ Time millisecondsToRun:
[1 to: 10 do: [:i | Browser fullOnClass: SystemDictionary selector:
#abandonSources].
self currentWorld submorphs do:
[:m | m delete. self currentWorld doOneCycle]].
self currentWorld addAllMorphs: saveMorphs.
time


----- Original Message -----
From: "Eddie Cottongim" <cottonsqueak at earthlink.net>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, April 09, 2003 6:37 PM
Subject: Re: [Q] scrolling large collections


> isVisible just checks the "visible" property. It doesn't tell if the morph
> is visible due to clipping regions. There are several methods that make
this
> optimization, but it does very little good as far as I know, since the
vast
> majority of morphs aren't set to invisible. Even if it did work, its still
a
> per-morph operation.
>
> StringMorph (down in the text drawing part) does figure out if its not
> visible on the current vancas. But it has to work down to a fairly lowel
> level before it kicks out.
>
> ----- Original Message -----
> From: "Ned Konz" <ned at bike-nomad.com>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, April 09, 2003 4:48 PM
> Subject: Re: [Q] scrolling large collections
>
>
> > On Wednesday 09 April 2003 01:33 pm, Eddie Cottongim wrote:
> > > By the way, although an ambitious changeset like Lex's Largelists
> > > may not be able to gain favor from n squeakers (gaining such
> > > acceptance would seem to be an O(N!) problem) we could do some
> > > minor things to help ScrollPane.
> > >
> > > Specifically, on every scroll it iterates through all its morphs (
> > > I think i'm getting this right!) to find their bounds. This as far
> > > as I can tell can be cached very reasonably to at least double the
> > > scrolling speed. Calculate it lazily, and invalidate it upon a
> > > #layoutChanged. This isn't a total speed fix but its simple and a
> > > considerable increment.
> > >
> > > If anyone is interested in such changes I'll prepare them (its
> > > perhaps 2 one-liners), but I'm inclined to believe no one is. Of
> > > course if I'm overlooking something fundamental please let me know.
> >
> > You must mean that Lex's change set does this. The stock code, as I'm
> > sure you know, just iterates through the morphs and draws each one to
> > a clipping canvas.
> >
> > It seems to me like the behavior of the stock drawing code can be made
> > a lot faster with large lists by a simple addition to ClippingCanvas:
> >
> > fullDrawMorph: m
> > (self isVisible: m fullBounds) ifFalse: [ ^self ].
> > super fullDrawMorph: m
> >
> > However, I haven't benchmarked it myself.
> >
> > Does anyone have a good benchmark for redrawing browsers (for
> > instance)? I think Andreas had posted something like that a while
> > ago.
> >