Best Squeak setup for servers

Andreas Raab andreas.raab at gmx.de
Fri Nov 14 23:41:48 UTC 2003


Hi Lex,

> I'm confused.  For local displaying, Morphic does operations on its
> local Display bitmap, and then the damaged areas get forced to the
> screen all at once.

I think what John is saying is that "all at once" is the problem. E.g., the
time needed for the flush can be significant if it's done synchronously and
making this asynchronous (e.g., send it _while_ Squeak is doing other stuff)
may improve performance. One of the things that might be worth a try is to
write a VNC server in Squeak which could serve the update regions based on
varying strategies - for example, start transmitting on #forceToScreen and
wait for the transmission to complete before we start drawing again.
Alternatively, hack the screen into portions of fixed size (patches) and
transmit entire patches when they changed (the server would only remember
the changed and transmitted patches). This could be done in combination with
some caching by the server so that drawing/transmitting can be done totally
asynchronously.

> I recall that it is important to support the
> semantics for the display to look correct; sometimes Squeak will
> intentionally do a display update followed by drawing essentially junk
> on the screen.  If you don't support the deferred screen updates, then
> you get the junk. (The specific case was dragging a morph using the
> hand; the drawing cycle involves drawing the dragged morph, 
> updating the screen, and then undrawing the dragged morph.).  See
> #displayWorld:submorphs:  for details; note the forceToScreen: that
> happens near the end of the method.

This is (I think) the only place where this happens and it is quite possible
to fix it. In general, it's not a good idea to rely on these side effects.

> Incidentally, if you really want high performance and are willing to
> spend some programming time to make it happen, then you are almost
> certainly better off by starting with Nebraska.

As always the truth is somewhere in the middle. The tradeoffs are quite
different. Indeed I would argue that a "mixed model" in Nebraska which
allows you to simply remember dirty regions of the (local) Display might be
a worthwhile addition (those would be send "VNC-style" at the end of the
update cycle). For example, this could be used to transmit fonts and
(static) forms lazily without having an initial hit on the bandwidth
required. So Nebraska could (initially) start out just sending bits, then
send more high-level commands.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list