caching of screen display...

Lex Spoon lex at cc.gatech.edu
Fri Dec 3 12:03:24 UTC 1999


There are other issues, too:

	- implementing paragraph drawing (the postscript guys can talk about
this too, I imagine :))
	- dealing with transformations
	- the myriad surrounding details of UI, getting the client connected to
the server, and dealing with network disconnects--ie, preferably you can
resume a disconnected session

Also, it might be nice to transmit 3D drawing commands across the
connection, a la the GLX extensions for XWindows.  It wouldn't be
ultra-fast, but it might be faster than transmitting bitmaps.

Lex




Ian Piumarta <Ian.Piumarta at inria.fr> wrote:
> > But I still think the real solution is to implement a proper display
> > server in Squeak;
> 
> I've thought about doing this several times over the past few years.
> The required protocol is really narrow, so it should not be much work
> at all.  The only tricky thing would be to integrate it properly with
> all the {8,16,32}{ML}SB -> {8,16,32}{ML}SB conversion functions.  Even
> run-length encoding (which is *fast*) to compress the transferred
> Display regions would win big -- and, combined with some kind of
> caching in the client side, might even make running over a modem
> perfectly feasible.
> 
> It's just waiting for a rainy weekend...  ;-)
> 
> Alongside 36 zillion other little "weekend projects"...  :-(
> 
> Ian
> 
> PS: The priority for me is low: local display with XShm and async
>     updates enabled (the only "serious" way to run Squeak ;-) is
>     instantaneous on any machine that isn't already in a museum.
> 
> PPS: The thing should be built as a plugin, naturally.  Being
>      able to assume (with certainty) that Unix is the local platform
>      opens up many interesting plugin possibilities...  :^p





More information about the Squeak-dev mailing list