From:  Dean Swan at MITEL on 03/20/2000 11:54 AM

>OR, as an alternative to all this mess, each morph could have a process that
>does stuff and then sleeps for a while.  The sleep code could be a call
>back to morphic, which suspends the process, to be resumed it again at
>the right time.  Coroutines, basically.  Such an approach ought to make
>programming graphic behaviors a real breeze!  It could be very similar
>to the simulations framework in the, uh, purple book, I think.


Lex,
     This is an excellent idea, and an appealing architecture (imo), *BUT* is
raises a lot of issues that would need to be dealt with.  The biggest one that I
can see is that redrawing of morphs would become much more complex because there
would no longer be an implicit ordering to how the morphs get drawn.  With the
stepping mechanism, the HandMorph "controls" (or at least "directs") the order
in wich the morphs get passed control for their re-draw, so overlapping morphs
are dealt with properly.

     I also think that  the ProcessorScheduler class and/or the context
switching mechanism in the VM might need a little re-work to support a more
completely pre-emptive scheduling environment.  Tim Rowledge has probably
already reviewed this stuff and would be aware of the issues due to his
"real-time" Squeak work.



                                   -Dean Swan

                                   dean_swan at mitel.com