Text preview for : Interlisp_Display_Primitives_Jul77.pdf part of xerox Interlisp Display Primitives Jul77 xerox alto memos_1977 Interlisp_Display_Primitives_Jul77.pdf
Back to : Interlisp_Display_Primiti | Home
INTERLISP DISPLAY PRIl\lITIVES
Robert F. Sproull
Xerox Palo Alto Research Center
3333 Coyote H iII Road
Palo Alto t California 94304
Version of July 1977
1. Introduction
This report describes briefly a set of display primitives that we have developed at PARC to
extend the capabilities of InterLisp[l]. These primitives are designed to operate a
raster-scanned displaYt and concentrate on facilities for placing text carefully on the display
and for moving chunks of an already-created display.
The primitives are deliberately designed to provide a low-level interface to the display. A
display output primitive will cause a specific change to appear on the display by changing
the contents of a frame bufler (or some other memory) that is llsed to refresh the
raster-scanned image. The primitives make no assumptions about the sorts of data
structures for describing the display that an application program may wish to build.
Our implementation of these primitives involves two computers: InterLisp is executed on
MAXC, and communicates with a program called Chat which maintains the frame buffer
that drives a 808 by 606 point raster display. Although the communications link ably
provides the bandwidth necessary to achieve rapid screen changes t it nonetheless requires
special treatment of synchronization. If these primitives were to be implemented on a
single computer that both executes InterLisp and performs the display modifications, the
synchronization problems could be ignored.
The design of this system is complicated by the need to accommodate on the display
ordinary "teletype" output generated by InterLisp and Tenex t as well as
carefully-constructed graphic displays. The primitives resolve this problem in a reasonably
effective way: the unformatted character output may be directed to a specific region of the
screen under complete control of the LISP program. However, we are forced to acknowledge
the existence of two independent sources of information for Chat: a stream of teletype
characters emerging from Tenex and a separate graphics connection that carries the
characters and graphics protocol generated by LISP. As with the Network Graphics
Protocol[2], it is important that these connections be kept separate: the graphics connection
must transmit highly structured protocol messages that cannot suffer interference from
system messages and other uncontrolled teletype transmissions.
2. Th.e ADIS functions
This report does not cover the detailed implementation of the system, but concentrates on a
description of the collection of LISP functions that are provided t and their intended effects.
Each function is named ADISXXX; the actual names of the functions use all upper-case
INTER LISP DISPLAY PRIMITIVES 2
letters, even though the description below does not.
ReselSave. Several of the functions for setting state variables use argument conventions
that permit lise with ResetSave. They have the following properties: (1) called with no
arguments, they return a "current state;" (2) when called with legitimate arguments, they
return the "current state" before the alteration induced by the arguments; (3) called with a
"current state" (either a list or a number) as argument, they reset their state. Functions