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
|