From: mcdaniel@decwrl.dec.com (Gene McDaniel) Subject: A summary of Gosling's SunDew window system Date: August 3, 1986 To: Xpert@athena.mit.edu Hearing Gosling talk about SunDew (for the second time) reminded me of this summary I wrote. Perhaps some of you will find this interesting. ------- Forwarded Message From: mcdaniel (Gene McDaniel) Date: 14 Jul 1986 1504-PDT (Monday) Subject: A SunDew summary. This is short report on SunDew a prototype window system built by James Gosling of Sun Microsystems. Monday, 23 June Scott Nettles and I attended BASS, Bay Area Systems Seminar where Gosling talked about SunDew. This document stems from my notes, conversations with Scott, and communications with Gosling. SunDew: Yet Another Window Server? SunDew represents something new and very exciting. Like X and Andrew it is a network-based window server, and not exactly a window system itself. Unlike X or Andrew, it is actually written in an extension of PostScript, Adobe's page description language. Client programs communicate with the server by sending messages containing PostScript programs. These programs can describe what marks should be placed on the screen (or on another device such as a laser printer). Gosling wrote his own parser, interpreter, and imager for PostScript. He extended the language by adding multiple drawing surfaces (canvasses), light weight processes, garbage collection, input events, and an encoded input stream. PostScript programs on the server can maintain long term state. Consider, SunDew is really a veneer of PostScript programs and the "read, eval, print loop" of a PostScript interpreter. The veneer (window manager, menu package, input system and initialization) is 603 lines of PostScript. Client programs can replace that veneer with one of their own, or they can paste another veneer on top it. Since the server is programmable in this way, the client can construct a user illusion that looks like X, Andrew, SunWindows or anything else. Gosling observed that it is very easy to write a parser and interpreter for PostScript -- about a week of work (for him). The imager was a year of hard work. The interpreter and imager were written in C. SunDew is written mostly in PostScript. There are some provisions for down-loading and executing C code. The down-loadable C code is used for debugging, only. Gosling commented that the dynamic loader isn't very fast (1-2 seconds to snap a link), and using down-loaded C code requires the client to know about the CPU architecture of the server. This is clearly a problem in heterogeneous environments. Within SunDew there are multiple processes. Light weight processes are important -- he *creates* a process on each button click of the mouse! Gosling worried about providing synchronization facilities, and finally decided not to provide them because he didn't understand exactly what he should do: he feels strongly he must see clear need for mechanisms before he is willing to design or implement them. So far this omission has not be a problem. Gosling: "So far, not a single instance of a synchronization problem has cropped up. This seems to be due to the lack of preemptive scheduling: it has very much the same feel as programming in Simula." SunDew is integrated with Sun's NFS, and code (including the code for newly created processes) may be loaded from the remote file server. Why PostScript? Gosling described numerous reasons for writing a PostScript interpreter and writing SunDew in PostScript. He did not want to design a new language since that is both hard and non-portable. As mentioned above, PostScript is very easy to parse and interpret; this helps a PostScript interpreter be very fast. PostScript keeps SunDew's data structures completely hidden from clients thereby providing both flexibility and speed. Flexibility comes from the fact the implementor can change the data structures and not worry about client compatibility, and speed comes from the fact the implementor can change the data structures in any fashion necessary to make the underlying machinery execute more quickly. Client programs pass PostScript programs as messages to SunDew. This furthers the goal of fast execution by reducing the amount of information that must be passed to cause changes on the screen. An example of this is to draw tick marks on the screen. In X or Andrew, the client must send a description for every point where a tick mark will be drawn. The SunDew client sends a short (two line) program that makes the tick marks. By reducing the number of messages that must pass between the client and the server he improves performance. You can think of these client programs as a dynamically changing protocols that suit the client's current needs. The encoded input stream provides further data compression. Finally, PostScript provides the right abstractions for a program that is concerned drawing images. Gosling hammered home these points when, during a video tape, we saw SunDew drawing "rubber-band" spline curves on the screen. The curve was tracking the mouse in real time! SunDew can implement this facility by passing a program to the server that causes mouse movements to be tracked in the server, and the appropriate splines to be drawn. The machine had NO special graphics hardware; the display was an array of pixels. The alternative approach, employed in X, for example, is to pass information regarding mouse movements to the client program. The client program then sends to the server information about how or where to draw the splines. This approach adds extra communication which becomes even more expensive as the client move further from the server (ie., when the client program moves to a different machine from the server machine). C, PostScript and SunDew Once adequate libraries have been constructed, applications programmers do not need to use PostScript. However, the "bare machine" executes PostScript programs and client programs must (eventually) send PostScript to the server. Not all programmers want to become jock PostScript programmers, and CPS is the program that tries to make C to PostScript communications easier. CPS reads a file that contains pairs of C procedure declarations and PostScript code fragments. When CPS reads such files it constructs a .h file that declares the C procedures implemented in the C source file that it also constructs. The when the client calls one of the procedures defined in the .h file, the C implementation transmits the appropriate PostScript code fragment to the SunDew server. Gosling's example was a C program that wants to display a go board with a few stones on it. Here's a fragment example of what would appear in the .cps file, go.cps: cdef initialize (x,y,width,height) x y width height newwindow clippath pathbox pop pop translate clippath pathbox 19 div exch ... cdef black(x,y) cdef white(x,y) ... This example declares three C routines, initialize, black, and white. Not shown is the PostScript code that actually defines black and white. In Gosling's example those code fragments were declared in the code for initialize. When the client calls initialize, the C program generated by CPS transmits the initialization PostScript code to SunDew. Notice that the initialization PostScript code also defined two more PostScript procedures, black and white. When the client subsequently calls black (or white) the C implementation simply sends to SunDew an invocation the function black (or white) with the appropriate x and y values. A client's C program that draws a go board and places a few stones would look something like this: #include "go.h" main { PostScript_OpenPostScript (); initialize (500, 100, 200, 200);/* define board, black, white */ black (7, 5); /* place a few stones */ white (7, 6); black (8, 6); PostScript_flush (); /* make sure SunDew receives all */ sleep (20); /* let user see it a while */ PostScript_close (); /* we're all done */ } Imaging Model Gosling believes the imaging model is crucial. The model he used is based on the stencil/paint approach from Cedar graphics and PostScript. The stencil is an infinitely thin boundary piecewise composed of curves. Paint is pure color or texture that may be applied through a stencil to the drawing surface (canvas). SunDew represents curves as conic projections after the fashion described by Vaughn Pratt in his SigGraph paper. That's the COMPLETE model! When I asked Gosling about the imaging model, and about colors in particular, he responded thusly: - Right now, colors are purely opaque. Revisions to the imaging model are being discussed now (with adobe). 3D and color are the two areas getting the most work. The implementation is easy compared to the task of coming up with a clean model. A high performance implementation is difficult, but possible. Gosling claims it took a week to do the PostScript interpreter and garbage collector, and it took him a year to get the imager to limp along. Gosling is unusually talented. Device Independence. One advantage of this approach is that clients get to ignore device differences, but not by using a least common denominator approach. The PostScript language provides device and resolution independence while the imaging model, which is driven by the PostScript interpreter, can exploit any specific knowledge of the device that may be available. This way high level abstractions really can exploit high performance displays. The imaging model provides arbitrary transformations between the image described in the program and the canvas. Thus the program can work in some arbitrary coordinate system, say mils, and the imager will make marks on the canvass taking into account the pixel realities. Note that font naming is resolution independent. Internationalization We saw a demonstration showing kanji support in a SunDew application. The major issues here, apparently, are to provide for flexible keyboard mapping (there are alternative keyboards for different situations), and define a font as a set of glyphs. There is mapping between byte streams and glyphs (built into SunDew) that does the rest. This arrangement also provides for kerning. Input Events We normally think of input events as relating to keyboard or mouse actions. In addition to hardware related actions, input events can be generated by PostScript processes. Input events are passed to the PostScript processor. Input events contain information like location, shape, name, action (up or down), and a time stamp. They can be used as templates to express interest. That is, the client can fill in an input event with wild card notations. Then the event can be passed to the server to indicate that the client is interested in a specific event or a class of events. The input dispatcher loops awaiting events. When it finds an event in which the client is interested, it recognizes the event and executes the code associated with it. Otherwise it does whatever is appropriate for single characters. Those of you familiar with emacs will find this paradigm familiar in as much as the value of an event may be simply itself (a character, for example), or it may signal the execution of some complex action. Gosling commented thusly about communication between the PostScript server and C clients: - The communication between the PostScript world and C clients is entirely up to the PostScript code. There is a facet to CPS which I didn't describe that lets you define return values for CPS functions. A lot of clients just send plain text. Status SunDew is up and running. Gosling describes it as "not too shaky." Gosling later commented: "'Not too shaky' means that it stays up for several days at a time.... Unless I've just been hacking on it." He and others are building utilities that use it. SunDew has an uncertain future. Licensing issues are unclear and under discussion at Sun. Gosling seems very concerned that something in SunDew see the light of day -- either Sun make a product of it or they allow him to publish a fuller description of it (as research). ------- End of Forwarded Message