James Gosling's article, "SunDew - A Distributed and Extensible Window System" from "Methodology of Window Systems" is a fascinating preview of NeWS, but even m

James Gosling's article, "SunDew - A Distributed and Extensible Window System" from "Methodology of Window Systems" is a fascinating preview of NeWS, but even more so is the transcript of the discussion between some amazing pioneers of interactive computer graphics who attended the the workshop where the paper was presented. I love how James gently humors the standards guy (P. Bono) who suggests he should have considered the glorious "CGI graphics model" (Core Graphics Interface) standard, and seems incredulous that he is "ignoring the standards" by choosing PostScript over his favorite standard of the day in 1985, CGI. My favorite quote is: "There is really nothing new here. It's just putting it together in a different way." -James Gosling SunDew - A Distributed and Extensible Window System, by James Gosling: Discussion http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... 5.4 DISCUSSION Chairman - George Coulouris Williams: What is the scope of the devices you are considering? I don't suppose you intend running the window manager on a graph plotter. Gosling: The crudest display we are willing to accept is 1 bit per pixel black and white but we also support 8 or 24 bits per pixel colour or 4 bits per pixel black and white. Williams: Essentially bitmap raster devices. Gosling: Right - although when you get to grey scale devices, things stop behaving in a model that is comfortably compatible with RasterOp. You have got to be able to deal with antialiasing, such things as subpixel positioning begin to make sense. It makes sense to draw a character midway between two pixels because you can use antialiasing to shift the character over by subpixel amounts. Bono: When you use the word PostScript, do you mean literally that PostScript is in some way your virtual machine instruction set? It has not been extended or generalized? Gosling: It has been extended. It is a superset. We are committed to implementing everything in the PostScript telephone book that makes sense. They have a few commands that are particular to their storage allocation and to the fact that they are going to a printer and these are not implemented. We have imported some things that are peculiar to a display and a small number of incompatible changes to the language have been made which we spent a long time talking to the people at Adobe about to make sure that was reasonable. In particular, we added garbage collection and lightweight processes. There are very tiny ways in which the semantics of PostScript's memory allocation strategy shows through in the printer version because they have a quick and dirty storage allocation mechanism and that wasn't really useful in this system. Bono: The virtual machine was not virtual enough. Gosling: Right. When we made the generalization to multiple processes, their storage allocation mechanism just completely broke and so we had to use garbage collection instead and that necessitated some small semantic changes but they are not things you are likely to see. All of the important things such as how you specify a curve, whether you can render an image rotated 37 degrees, all of that is there or intended to be there. Hopgood: How do you handle input? Gosling: Input is also handled completely within PostScript. There are data objects which can provide you with connections to the input devices and what comes along are streams of events and these events can be sent to PostScript processes. A PostScript process can register its interest in an event and specify which canvas (a data object on which a client can draw) and what the region within the canvas is (and that region is specified by a path which is one of these arbitrarily curve-bounded regions) so you can grab events that just cover one circle, for example. In the registration of interest is the event that you are interested in and also a magic tag which is passed in and not interpreted by PostScript, but can be used by the application that handles the event. So you can have processes all over the place handling input events for different windows. There are strong synchronization guarantees for the delivery of events even among multiple processes. There is nothing at all specified about what the protocol is that the client program sees. The idea being that these PostScript processes are responsible for providing whatever the application wants to see. So one set of protocol conversion procedures that you can provide are ones that simply emulate the keyboard and all you will ever get is keyboard events and you will never see the mouse. Quite often mouse events can be handled within PostScript processes for things like moving a window. Sweetman: How do windows relate to canvases? Gosling: I did not use the word window because its overloaded with all kinds of semantics. Does it have a border? All that a canvas is, is a thing on which you can draw. It is not even rectangular. Sweetman: Do you see canvases on your display? Gosling: Yes you can. A canvas is a thing on which you can draw. It might be visible on some display and it might not. If it is visible, you can specify its position in a 2.5D coordinate system. It is opaque but you can get a transparent effect if you want something to show through a window, by cutting a hole in the window. Williams: You say clients have to accept redraw commands. Is there any indication as to how soon they are supposed to do them? Gosling: The client can ignore the request if it wants. The screen image will look a little funny. Or it can wait half an hour - it does not affect the integrity of the screen. It will affect the integrity of its window but nothing else because all the canvases are maintained in apparent isolation from each other. Williams: Will the visual image just contain what was there before? Gosling: You can do that, if you wish. For most applications it does not make any sense to retain the old bitmaps so you might as well just blow them away and replace them by whatever is most convenient - which is probably what was there before. There are some times when you would like to retain the old bits - that is there as an option. I really want to make it difficult for people to exercise that option as it is a very tasteless thing to do in general. Bono: I hope I am not being overly opaque about this but it seems like I have a sense of deja vu in that it's a lot better way of doing what people did with display lists, where you sent things down to Vector Generals or whatever. They were little programs and there was some grouping structure but everything is done so much nicer now in the sense of having complete programs and a better set of primitives etc. Am I missing something from the model or is that really what is going on? Gosling: One of the things that tended to characterize all the display list languages was that they tended to be tailored very much towards what the hardware could do. PostScript tries to stand back and say "I don't want to know what the hardware can do, I want to know what makes sense for the user". Bono: What I would like people to do when they do look at standards, instead of ignoring them, is to look at, for example, the CGI work; this is a set of functions which some people claim is a good instruction set (forget the syntax for the moment, just look at the functionality). We would like to get some comment on whether it is a good set of functions and that is what you should be looking at rather than ignore the standards. All of this could be fitted in a standards context if we get it right. Gosling: One could easily use the CGI graphics model for this instead. Teitelman: The innovation here is not that we are using PostScript. The reason we chose PostScript is due to a lot of historical connections and proximity to the people who are doing it. The interesting thing is that all these processes look as though they are executing in one of those old single address environments. It is a single user process that James has been able to implement lightweight processes in. You don't have lightweight processes in Unix systems, which you really need to implement realistic user interfaces. Gosling: There is really nothing new here. It's just putting it together in a different way. Rosenthal: It is worth bringing out a number of points about this style of window manager. There are some real limitations, though I think this is the way we should go. Some help from the kernel is needed. This is easy in 4.2 which has a sensible IPC. It could be done in System V through shared resources etc. A reliable signal mechanism is essential. The window manager has to stay up. It is the only routine for talking to the system and hence must stay alive. We have 100 systems running and only experience 1 - 2 crashes per week. This is good by Unix standards! Applications cannot read pixels back - this is just too slow. There must be a way to make the client think it has a real terminal, such as the 4.2BSD PTY device, otherwise all old programs misbehave. There must be a mechanism for downloading application code into the window manager process, for example, rubber band line mouse tracking is done by a user level process. There must be off-screen space in the window manager. Examples of systems built in this way are: BLIT [50]; Andrew (CMU)(see Chapter 13); VGTS (Stanford) [36]; X (MIT). The BLIT system is successful - people wrote programs for it. I believe it is the only successful window manager for a Unix system. Myers: Maybe that is because BLIT doesn't run a Unix operating system. Rosenthal: Overall, it is a Unix software environment. Williams: We should bear in mind that Rob Pike says that to do anything sensible using the BLIT, you need to write two processes which communicate: one running in the Unix host and one running in the BLIT, and this must be harder to do than, say, writing two programs which don't communicate.