At 11:45 AM +0100 2/16/98, Thierry Goubier wrote:
>What's needed is then a redesign of the VM so that the Display object
>behaves like a true buffer (i.e. doesn't call for an immediate update when
>displaying on it, and manages a forced update at regular intervals). To do
>that, I need to modify the VM source and recompile one, and I also need to
>rewrite part of the UI so that screen updates are correctly managed.
>
>It sounds plausible, and I'm ready to try this second alternative. What I
>plan to do is this:  to add a damage rectangles management behavior inside
>the VM (so that each primitive on the Display will generate a damage
>rectangle) and a time-based process in the Smalltalk side for managing
>updates. The damage rectangle management will include some code to merge
>incoming rectangles. 

Thierry:

Andreas's Windows VM does things almost exactly as you describe,
using the Window's damage list to accumulate damage. There is
primitive that can be used to force the damage list to be be
processed on demand. Otherwise, it happens automatically after
a certain time interval or when the damage list gets long
enough.

So, if you have a Windows VM you might experiment with that before
building your own VM. Or you might look at how Andreas implemented it,
since the same techniques can probably be used with other windowing
systems (e.g., the Mac).

We've considered doing precisely this optimization, but to
save memory space rather than speed. The extra copybits turns
out to be surprisingly cheap.

One possible future direction for Morphic is to have every Morphic
World be in its own platform-native window. Thus, the FormCanvas
for a MorphicWorld would play the role currently played by the
Display and the would be no global Display object. This would, of
course, require a new set of primitives to create and manage native
windows and a new user input event mechanism, but the Morphic
architecture was designed to support it. The original Morphic
was implemented in Self and mapped each Morphic World to an X
window. It also supported multiple (remote) windows on the same
MorphicWorld and multiple user input streams, so it was possible
have several remote users interacting in the same Morphic
World. Randy Smith even tried some trans-Atlantic interactions
between California and England. Network latency made things
interesting, but it was quite a lot of fun! Collaborations among
two or three users on the same local-area network.

	-- John