SunDew is a distributed, extensible window system that is currently being developed at SUN. It has arisen out of an effort to step back and examine various window system issues without the usual product development constraints. It should really be viewed as speculative research into the right way to build a window system. We started out by looking at a number of window systems and clients of window systems, and came up with a set of goals. From those goals, and a little bit of inspiration, we came up with a design.
A clean programmer interface: simple things should be simple to do, and hard things, such as changing the shape of the cursor, should not require taking pliers to the internals of the beast. There should be a smooth slope from what is needed to do easy things, up to what is needed to do hard things. This implies a conceptual organization of coordinated, independent components that can be layered. This also enables being able to improve or replace various parts of the system with minimal impact on the other components or clients.
Similarly, the program interface probably should be procedural, rather than simply exposing a data structure that the client then interrogates or modifies. This is important for portability, as well as hiding implementation details, thereby making it easier for subsequent changes or enhancements not to render existing code incompatible.
Retained windows: a clean programmer interface should completely hide window damage from the programmer. His model of a window should be just that it is a surface on which he can write, and that it persists. All overlap issues should be completely hidden from the client. I believe that the amount of extra storage required to maintain the hidden bitmaps on a black and white display is negligible - based on the observation that people generally do not stack windows very deeply. The situation is somewhat different with colour, but there are games to be played. Retained windows is one way of hiding window damage, but we do not want to commit to a particular solution to this problem at this time.
Flexibility: users need to attach devices, change menu behaviours and generally modify almost all components of the system. For example, the menu package ought to be independent of the particular format or contents of the menu, thereby allowing the user to develop his own idioms without having to reimplement the entire system.
Part of flexibility is device independence: SUN provides a spectrum of display devices to which clients need consistent and transparent interfaces. This leads directly to portability, which we also need to achieve.
Users should be able to make various tradeoffs differently than in the standard system, because of either particular hardware or performance requirements. For example, if the system provides retained windows because we believe that the cost in terms of memory usage is worth the performance improvements, a user should be able to make this tradeoff differently, for example if he has less memory.
This extreme flexibility might appear to be at odds with having a clean, simple, well-abstracted programmer interface, but we do not believe that it is.
Remote access to windows: in the kind of distributed networked environment that SUN promotes, it is natural to want to be able to access windows on another machine as naturally as the NFS promises to support accessing remote files. We believe that this will fall out of any reasonably designed system.
Powerful graphical primitives: the primitives that the Macintosh provides should be considered as a lower bound. Curves and colour need to be well integrated. Attention should also be paid to what CGI [30], GKS [28], CORE [24] and PHIGS [6] need. A consequence of an emphasis on power and flexibility is the ability to emulate other window systems, eg it would be very valuable to be able to provide an emulation of the Macintosh toolbox.
Exploit the hardware: in particular, none of the systems mentioned above deal well with colour. In the future, colour is going to play an even larger part in display design. One can view black and white as a temporary technological stopgap, just as happened with television. Besides, SUN makes some pretty good colour displays, so the window system should exploit them. One implication of this is that the font file format must completely hide the details of the representation of characters, since we might eventually want to support antialiased text, and even illuminated monastic typefaces.
Perform well: the performance of the current window system should be considered as the minimum acceptable level. Performance in the common cases is especially critical. The new system should perform faster than the current system on such common operations as repainting and scrolling of text.
The work on a language called PostScript [1] by John Warnock and Charles Geschke at Adobe Systems provided a key inspiration for a path to a solution that meets these goals. PostScript is a Forth-like language, but has data types such as integers, reals, canvases, dictionaries and arrays.
Inter process communication is usually accomplished by sending messages from one process to another via some communication medium. They usually contain a stream of commands and parameters. One can view these streams of commands as a program in a very simple language. What happens if this simple language is extended to being Turing-equivalent? Now, programs do not communicate by sending messages back and forth, they communicate by sending programs which are elaborated by the receiver. This has interesting implications on data compression, performance and flexibility.
What Warnock and Geschke were trying to do was communicate with a printer. They transmit programs in the PostScript language to the printer which are elaborated by a processor in the printer, and this elaboration causes an image to appear on the page. The ability to define a function allows the extension and alteration of the capabilities of the printer.
This idea has very powerful implications within the context of window systems: it provides a graceful way to make the system much more flexible, and it provides some interesting solutions to performance and synchronization problems. SunDew contains a complete implementation of PostScript. The messages that client programs send to SunDew are really PostScript programs.
Two pieces of work were done at SUN which provide other key components of the solution to the imaging problems. One is Vaughan Pratt's Conix [53], a package for quickly manipulating curve bounded regions, and the other is Craig Taylor's Pixscene [63], a package for performing graphics operations in overlapped layers of bitmaps.
Out of these goals and pieces grew a design, which will be sketched here. The window system is considered in four parts. The imaging model, window management, user interaction, and client interaction. The imaging model refers to the capabilities of the graphic system - the manipulation of the contents of a window. Window management refers to the manipulation of windows as objects themselves. User interaction refers to the way a user at a workstation will interact with the window system: how keystrokes and mouse actions will be handled. Client interaction refers to the way in which clients (programs) will interact with the window system: how programs make requests to the window system.
What is usually thought of as the user interface of the window system is explicitly outside the design of the window system. User interface includes such things as how menu title bars are drawn and what the desktop background looks like and whether or not the user can stretch a window by clicking the left button in the upper right hand corner of the window outline. All these issues are addressed by implementing appropriate procedures in the PostScript.
Imaging is based on the stencil/paint model, essentially as it appears in Cedar Graphics [65] and PostScript. A stencil is an outline specified by an infinitely thin boundary that is piecewise composed of spline curves in a non-integer coordinate space and which may be self-intersecting. Paint is some pure colour or texture even another image - that may be applied to the drawing surface. Paint is always passed through a stencil before being applied to the drawing surface, just like silkscreening. This is the total model: lines and characters can be defined using stencils. Lines are done as narrow stencils - underneath it all, it is not really done this way: special cases are exploited wherever possible.
One can think of a stencil as a clipping region. Stencils may be composed by union, intersection and difference to create new stencils.
The Macintosh graphics system, QuickDraw [18], can be easily cast in this framework: their GrafPort is simply a paint box, and all of the shapes that can be drawn are subsets of the capabilities of stencils. Many other 2D standards fit in easily as well, and the extension of the model to 3D is relatively straightforward.
Vaughan Pratt's work on conic splines presents us with an opportunity actually to realize this model and achieve good performance.
Almost all imaging functions are provided not by the window manager but by PostScript processes. For example, if one wanted rounded rather than square corners on a menu package, this could be done by modifying a PostScript procedure. Scope rules determine whether modifications are global or local.
Pixscene [63] makes windows cheap and easy to create. If a client wants to create a window quickly as a pop-up, the window system will handle it. It very efficiently makes sure that each window is always complete: overlap is not visible to the client.
Even though windows behave as though the image is retained, clients will have to deal with requests to redraw from the window system. This will generally only happen when a window is stretched, in which case the client probably has no use for the old image, anyway.
Pixscene is based on a shape algebra package. The ability, provided by Conix, to do algebra very rapidly on curves should make non-rectangular windows perform well.
The key word in the design of the user interaction facilities is flexibility. Almost anything done by the window system preempts a decision about user interaction that a client might want to decide differently. The window system therefore defines almost nothing concrete. It is just a loose collection of facilities bound together by the extension mechanism.
Each possible input action is an event. Events are a general notion that includes buttons going up and down (where buttons can be on keyboards, mice, tablets, or whatever else) and locator motion.
Events are distinguished by where they occur, what happened, and to what. The objects spoken about here are physical, they are the things that a person can manipulate. An example of an event is the E key going down while window 3 is current. This might trigger the transmission of the ASCII code for E to the process that created the window. These bindings between events and actions are very loose, they are easy to change.
The actions to be executed when an event occurs can be specified in a general way, via PostScript. The triggering of an action by the striking of the E key in the previous example invokes a PostScript routine which is responsible for deciding what to do with it. It can do something as simple as sending it in a message to a Unix process, or as complicated as inserting it into a locally maintained document. PostScript procedures control much more than just the interpretation of keystrokes: they can be involved in cursor tracking, constructing the borders around windows, doing window layout, and implementing menus.
Synchronization of input events: we believe that it is necessary to synchronize input events within a user process, and to a certain extent across user processes. For example, the user ought to be able to invoke an operation that causes a window on top to disappear, then begin typing, and be confident about the identity of the recipient of the keystrokes. By having a centralized arbitration point, many of these problems disappear.
Client interaction with the window system can be broken down into three layers: messages that get passed between the window system and the client, the programs that are contained in the messages, and a procedural interface to program construction. This is one of the key unique points about this window system: clients send programs to the window system whose elaboration causes graphic operations to appear. The client program does not send graphic operations directly. There is, of course, a procedural interface to program construction that blurs the distinction.
This approach allows the client to redefine the protocol to compress messages passed to the window system. For example, if the client wishes to draw a grid it can download a procedure which iteratively draws the lines, generating their coordinates as a function of the loop index. This is a substantial compression over transmitting a large set of lines, even if the grid is drawn only once. There are other performance advantages: message-passing interactions are relatively slow and downloading a procedure that will respond locally eliminates this overhead. For example, if a client program needs rubber band lines, then rather than have the window system send a message to it each time the mouse moves, it can download a procedure that will track the mouse locally.
There are a number of features of PostScript that make it attractive. It is very simple, and it is complete. Its simplicity makes it fast to translate and interpret - this can almost be done as quickly as packets can be disassembled in a more traditional IPC environment. Adobe did a very good job of designing a set of primitives and data structures that fit together well. Its chief drawback is that it can be hard for people to understand; the postfix notation is well-suited to consumption and generation by programs, but humans find it obscure.
It is important to think about the client programmer's model of what the window system does. We expect there to be two levels of model. The first completely hides the existence of PostScript with a veneer of procedure calls that construct and transmit fragments of PostScript programs. The second exposes PostScript. Beyond a certain level of functionality, learning PostScript is inevitable: it can be pushed off by making the veneer more comprehensive, but this just makes the eventual leap harder.
In order to give a flavour of PostScript, a small example is given in conclusion.
The PostScript code to generate the figure shown in Figure 5.1 is:
clippath pathbbox new path 2 div exch 2 div exch translate 250 250 scale 90 rotate 25 (0 .9 moveto 0 0 1 90 -90 arc 0 0 .9 -90 90 arcn fill .88 .88 scale 22.5 rotate) repeat
The first three lines set up the environment, centre the image and set up the transformation matrix. Then the coordinate system is changed by scaling down .88 in both directions and rotating 22.5. This is repeated 25 times.