I used to run X over a 33.6.  It was a dog, but it was reminiscent of
running it on a Mac IIcx with NetBSD.  I got productive work done!  If
Morphic were retrofitted with a display server, it would be trivial to
build classroom applications, with real-time sound and video being the
biggest bandwidth problems.  The SRC folks came up with a distributed
teaching tool that used Network Objects, a predecessor to RMI.

-John

> -----Original Message-----
> From: Lex Spoon [mailto:lex at cc.gatech.edu]
> Sent: Thursday, December 02, 1999 10:17 AM
> To: squeak at cs.uiuc.edu
> Subject: RE: caching of screen display...
>
>
> "Raab, Andreas" <Andreas.Raab at disney.com> wrote:
> >
> > > > For example, setting "PasteUpMorph MinCycleLapse:
> 1000" should reduce
> > > > network traffic pretty far, too....
> >
> > Yes, but it has currently bad side effects (such as that
> Morphs won't step
> > for this period of time).
>
> True, but typical values are more like 10-30, which are
> also the kind of
> values that John was talking about for practical use.  This causes a
> frame limitation of 30-100 fps, and morphs are inactive only between
> "frames"; but you probably *want* them to be deactive at
> those times so
> as to save CPU.
>
> I guess there could be benefit from having a higher framerate within
> Morphic, and then limitting the frequency that actual
> frames get posted.
>
> But I still think the real solution is to implement a proper display
> server in Squeak; then bandwidth should go down
> tremendously for most
> purposes (3D explicitly excluded :|), and a T1 should be
> plenty fast to
> run morphic at 60 fps.  (And a modem might never be fast
> enough to run
> Squeak reasonably, under any level of effort, though I'd love to be
> proven wrong)
>
>
> Lex
>
>