From:  Dean Swan at MITEL on 03/20/2000 07:19 PM

Jim,

     Yes this would amount to asynchronous processes, and as the system is
currently set up, and in your example, the asynchronous process is only
simulated within the scheduling loop of "PasteUpMorph>>doOneCycleNow".  This
involves Smalltalk code scanning through the lists of submorphs, and HandMorphs,
running the step methods, and updating the display with the damage rectangles.

     There is a *lot* of overhead involved here, and remember that even on a
fairly fast machine (i.e. a Pentium II/450, or a G3/333), you only get about 20
million bytecodes/s and 1 million message sends per second.  The message sends
per second is the real bottleneck, and the current structure requires many
message sends per morph just to figure out if there is anything to do for each
morph.  Using VM level process, which are also supported by the current system,
this could be significantly more efficient.  There are however, still some
issues regarding pre-emption and latency, and these are the things that Tim
Rowledge has done a lot of work on.

     Real time systems in-general span a spectrum from completely polling based
(i.e. just one big loop) to fully pre-emptive and event/interrupt driven.  A
very tight polling loop based system is going to waste far less CPU time on
"housekeeping" type things like context switching, but all of the things that
need to run in the system have to be very carefully coded to "play nice
together", and a small error in any component can cause the other components to
"fail", in a "met-my-real-time-deadline" sense.  To do this, one element of the
processing loop only needs to "hog" the CPU for "too long".  This is what the
current morphic scheduler, as implemented in 'PasteUpMorhp>>doOneCycleNow' is.

     The other end of the spectrum is to have a completely event and/or
interrupt driven system, where the processor defaults to running in a tight idle
loop, and switches to a new process context when an event ocurrs that requires
servicing.  Of course all the interrupts or "events" need to be prioritized to
ensure that "important" things happen before "less important things".  The
disadvantage of this architecture is that a lot more overhead is spent in
context switching, but now the individual software components become simpler to
code because no one process will be able to hog all the CPU.  This type of
architecture also makes it easier for a large base of developers to contribute
to a project because each software component can be designed as if it were
running on it's own independent processor.  Squeak makes this a little less
clear in that the multiple VM level processes share a single global object
memory, but this can be viewed as a "multiprocessor shared memory" system.

     Also, as you said, having a single thread of control for both timing and
display updating is both a blessing and a curse.  The positive side is that
there is a single place in the code where you can "catch-and-filter"
*everything*.  The negative side of this is that this powerful single control
point can also become a bottleneck, and provides a single point of failure.

     If all morphs ran as independent process and were truly responsible for
drawing themselves (i.e. not just telling the World that they need to be drawn,
and "oh, by the way, here are the bits to do that"), there would be a major
issue of synchronizing the whole display update process.

     Perhaps Andreas Raab would share his views on this whole issue, because I
know he has been thinking about it.


                                         -Dean Swan
                                         dean_swan at mitel.com








"Jim Benson" <jb at speed.net> on 03/20/2000 06:22:26 PM

Please respond to squeak at cs.uiuc.edu

To:   squeak at cs.uiuc.edu
cc:    (bcc: Dean Swan/Ogd/Mitel)

Subject:  Re: [?] Timers & Stepping



Dean,

>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!

Hmm, this sounds like an asynchronous process to me. I think you can do this
currently. See: http://minnow.cc.gatech.edu/squeak/1258. As Lex notes, you
don't have the capability of doing right now is schedule a message send at
an absolute time. You could always reschedule yourself after you are done
with your cycle and have the World scheduler wake you up after a certain
amount of time has elapsed.

I've got to tell you up front, you people are scaring me. The way that
Morphic is layed out now assumes that there is one Morph ( the World ) that
is responsible for both the timing and the screen updating. That is both
good and bad.

The good bit is that there is one place where all of the time scheduling and
drawing gets taken care of. Of course, that's also the bad bit. The real
trick in animation is how you synchronize all of your events that you need
to process, especially ones that have different timebases/timescales? Or
different priorities. I'll give you an example.

Let's say we're going to create a movie morph. The movie morph has two
components, the frames that are displayed, and the sound that is played. For
the sake of argument, let's say that on a slower machine it's acceptable to
drop frames, but never break up the audio. OK, so we have sound that is
sampled at 44.1khz and frame speed of 30fps ( Two different timebases, two
different priorities). One way to do this is as you folks have suggested,
run two processes, each process responsible for their own display or audio.
How do you synch the two, and in the case of dropped frames, how do you tell
what which frames to drop? This is hard because you don't really have a
sense of "movie time", you just have absolute time rolling by.

In the Morphic stepping scheme, you have a scheduling mechanism that
controls both consumers, so the frame drop outs occur naturally. The current
glitch is that Morphic doesn't have a very robust timing or sophisticated
priority scheduling mechanism, but that's a different problem.

> the order in which the morphs get passed control for their re-draw, so
overlapping morphs
> are dealt with properly.

As you know, it is the basic structure of a Morph which controls how it gets
redrawn. It's just that the World is the top level Morph, so all it does is
draw itself and occluded submorphs get taken care of naturally. So it's not
something that we really worry about. In another context, we would just call
a WorldMorph a display list, with some management code that keeps track of
the damage rectangles, who's visible at the current location, etc. The
display really isn't part of which stepping/animation  mechanism we're using
per se.

Jim Benson