Eddie,

> It will only help on slow systems.

I wasn't asking it it "will" - I was asking if it "does" ;-) E.g., when
it comes to optimization it's only the numbers that count. Make up a
case, show some numbers, show the improvement and noone will object.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Eddie Cottongim
> Sent: Friday, October 18, 2002 9:36 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Investigating fullBounds/layoutChanged
> 
> 
> Andreas said:
> > But does it improve anything?! If not, the added complexity 
> is hardly
> > worth it - you are making a very special case here and if 
> there's ever a
> > time where the hand _should_ be sending #layoutChanged you 
> may have a
> > hard time finding the place. So unless you can show that it improves
> > something I have reservations to make this optimisation.
> 
> It will only help on slow systems. There will be no noticable 
> effect on a 2
> ghz P4. Since mouse events come in about a fixed 35hz rate, the faster
> machines will spend proportionately less time on mouse 
> events. Measurements
> I give here are for my slow (133mhz) system.
> 
> First, Squeak is using 60-100% of the CPU just to move the 
> mouse around. It
> doesn't hurt Squeak directly, but its not nice behavior. I'm 
> not sure how to
> explain to people why this ok for Squeak. (I don't trust 
> Window's report of
> 60-100% usage - message tally says that 30% is spent in 
> Delay-Wait, so maybe
> 30%-70% is a better estimate).
> 
> Then there is battery usage. 40% (the time spent doing 
> fullBounds) of your
> battery power during mouse moves is being used for something 
> we can skip
> completely. I'm not an expert on how these systems manage 
> power and how much
> this will improve things, but it certainly ought to help.
> 
> Changing this isn't too complex - it boils down to changing 
> this line in
> Morph>>position:
>     owner ifNotNil:[owner layoutChanged].
> to:
>     self isHandMorph ifFalse:[owner ifNotNil:[owner layoutChanged]].
> 
> (or something similar, this is much simpler than the stuff I 
> sent before)
> 
> I agree that we should think very carefully about if the hand 
> ever should
> send layoutChanged as a result of a mouse move. If it 
> happened, this would
> mean that the world wants to move around its submorphs as a 
> result of mouse
> moves (which I think is pretty strange, but lets assume its possible).
> 
> If the world wants to move its submorphs as a result of mouse 
> moves, it
> could do it two ways:
> 1) use the normal event handling
> 2) depend on the current layoutChanged behavior
> 
> Doing it in way #1 seems better to me - this is the way other 
> morphs do
> this, and the code for it will be fairly clear.
> 
> So far it seems there is no reason that Worlds should expect 
> to be getting
> #layoutChanged from Hands.
> 
> Eddie
> 
> 
> 
> 
> 
> 
>