Also, don't forget that morphic animation of dragged objects can be 
turned off on slow machines, etc.

Cheers,

Alan

-------

At 2:09 PM -0700 8/1/02, Tim Rowledge wrote:
>In message <a05100307b96e66509feb@[10.0.0.2]>
>           Bruce Cohen <brucecohen at qwest.net> wrote:
>
>>  At 3:16 PM -0700 7/31/02, Tim Rowledge wrote:
>>  >b) that morphic is close to unusable on my pBook 400 OS-X machine and on
>>  >my linux machine (p3/800 or something) these days.
>>
>>  Hmm ... I'm using 3.2 gamma with all updates on a 400 meg PowerBook
>>  OS X right now and doing almost nothing  *but* Morphic programming.
>>  Its' not super-speedy, but performance is OK except when I try to run
>>  too many things at once (like putting "self halt" in a  method that
>>  gets called every 20 milliseconds from a separate thread; very droll
>>  :-(.   The one place where I would like more performance is when
>>  trying to playback a previously recorded event stream; sometimes the
>>  playback just can't keep up if there's something else going on.  But
>>  that's also somewhat of an edge case.  What performance problems are
>>  you seeing?
>General tardiness in a non-descript way. I suspect that it's not so much
>Morphic qua Morphic, but inadequately optimised applications of it. For
>example, opening a menu in many browser places is taking maybe a quarter
>second, which might sound good but is actually almost perfectly
>irritating. Anything over 0.1 sec for something like that is just plain
>bad. On my Acorn machine for example, native menus typically appear
>about synchronously with the mouse button click reaching ones ear.
>Really! Remember, this is a _slow_ machine as well.
>
>I suppose we really need some good meaningful test scenarios that can be
>automated and profiled to really try to sort this out. Then we could
>find out where the time is really going and do something about it. It
>wouldn't shock me to find out that somethings are being done two
>or more times instead of once, for example. Some sensible caching might
>prove useful.
>
>tim
>--
>Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
>Machine independent code isn't.


--