We have modified the X11R3 window server to allow a color Sun display to support up to eight monochrome virtual screens. Only one virtual screen is visible at a time, but switching between virtual screens (using the mouse, keys, or under program control) is very fast, since it requires only the reloading of the color map. We discuss the concept and implementation of virtual screens, how they can be used, and some limitations and generalizations of the concept.
Window systems are becoming quite commonplace. A window system controls access to a display terminal, allocating space on the display to multiple activities. This allows the (human) user to have several (possibly unrelated) programs running at the same time. The output of each program is displayed in its own window.
Window systems greatly improve the ease of working with a multi-process interactive computer system. Especially with a large high-resolution display, it is possible to have many windows on the display at the same time.
Over the past few years, the value of window systems has become increasingly apparent, and many window systems have been developed. Many new computer systems (such as the Macintosh, Amiga, and NeXT computer systems) come with a window system which is an integral part of the basic software. In other cases, a window system can be written as a user-supplied program. This encourages the creation of many different window systems. For example, many window systems have been written for the Sun workstation, including SunView [Sun 1986], the Andrew window manager [Morris et al 1986], the X window system [Scheifler et al 1986], NeWS [Gosling 1986], and GMW [Hagiya 1987]. These window systems are quite different in the specifics of their use. At the same time, they have many common properties.
The X11 window system is of particular interest. The X Consortium at MIT supports the core server code and some basic clients. There is also a large amount of contributed software. The source code for X11 is distributed freely and can be run on many different workstations. X11R3, the third source release of X11 has drivers for Sun, MicroVax, Apollo, HP, IBM/RT and Macintosh II workstations.
There are problems with the X11R3 window server, however. While the code provided by the X Consortium does compile, install, and run (quite well) on many different workstations, it is considered ``sample server'' code and is not, generally, complete production quality code. A particular problem, for example, is speed. The sample server code is often slow, since it emphasizes portability over speed.
The slow server speed is particularly noticeable with the color Sun support. Many bitmapped displays map the bits controlling the display image directly into memory. This allows standard programming techniques to directly modify the display by simply changing the values of memory bits. Generic code for supporting memory-mapped displays is included in the X11R3 sample server and the Sun sample server uses this generic code to drive its displays.
The use of the generic server code to drive a monochrome (black/white) server is acceptably fast, since each display pixel is only one memory bit. Color displays are more complicated, however. The Sun color display, for example, is typical of many color displays. The display needs 24 bits per display pixel: 8 bits of red, 8 bits of green, and 8 bits of blue. To reduce memory requirements, however, only 8 bits are stored for each pixel. This 8-bit value is an index (0 to 255) into a color map table of 24-bit color values. By reloading the color map, any color can be obtained, but only 256 distinct colors may be on the screen at any one time.
The Sun color display allows the color display memory to be viewed as one bit plane of 8-bit bytes (each byte holds the color map index for one pixel) or as 8 1-bit bit planes. Each bit plane is the size of the physical display. If the display memory is viewed as 8 1-bit bit planes (rather than one 8-bit bit plane), the color map index for a given pixel is determined by the 8-bit value selected by picking one bit from each bit plane to define the 8-bit color map index.
To save on program size and development time, the Sun sample X11R3 server uses the generic monochrome support code for its color support. For a color operation, the monochrome code is called 8 times (once for each bit plane) to affect each of the 8 bits per pixel for a color display. This slows color Sun displays considerably, almost by a factor of 8, but did not require a large amount of additional code to operate on 8-bit bit planes.
To avoid this particularly slow color Sun problem, Adam de Boor of the University of California at Berkeley, modified the color Sun driver to optionally operate in ``mono'' mode. In mono mode, the Sun driver ignores all but one bit of the 8-bit color pixels and consequently operates as a monochrome display at monochrome speeds on the color Sun display. The other bits of the color display memory are ignored by careful setting of the colormap. In particular, if all even (xxxxxxx0) color map entries are set black and all odd (xxxxxxx1) color map entries are set white, only the bottom bit plane defines the image on the display. This means that the device driver code need only modify one of the 8 bit planes to display an image.
At MCC, we have generalized this mono mode to provide a new means of using a color display. Rather than using only one of the 8 bit planes in the color Sun display to hold and display a monochrome image, our X11R3 server allows up to eight separate monochrome screens, one in each of the 8 bit planes of the color Sun display.
We have already seen that the image in the bottom bit plane can be used to define the display image by setting even (xxxxxxx0) color map entries to black and odd (xxxxxxx1) color map entries to white. Suppose instead that the first 128 entries of the color map are set to black and the last 128 entries are set to white. For this color map, only the bits in the top bit plane can affect the color displayed on the screen. That is, any 8-bit color index of the form 0xxxxxxx will display black and any 8-bit color index of the form 1xxxxxxx will display white. Only the top bit plane affects the image on the display.
In general, a specific pattern of black/white color map entries can be defined for each of the 8 bit planes to make it visible on the display (and all others invisible). Each bit plane defines a separate ``virtual screen''. Each virtual screen is the same size (width and height) as the physical display screen. At any given time, the user has selected a particular virtual screen. The selected virtual screen is shown on the physical display. If the user changes the selected virtual screen, the contents of the old virtual screen are saved and the newly selected virtual screen is displayed.
Each virtual screen is black and white (not color) and so only needs one bit to specify each pixel. Each virtual screen is kept updated in the appropriate bit plane of the display memory. Notice that it is not necessary to restrict virtual screens to black and white -- any two colors (background/foreground) will do. In fact, we find it convenient to define each virtual screen to have different background/foreground colors to aid in identifying them.
The physical display can be thought of as a viewing port onto the virtual screens: it allows the user to see any one (but only one) of the virtual screens at a time. Alternatively, the virtual screens can be considered to be paged into and out of the physical display, much like a demand-paged memory management system. Changing to a new virtual screen requires only loading a new color map, a very fast operation.
Virtual screens are selected (in our implementation) by the user. We have three selection methods.
How can multiple virtual screens be used? Over two years ago, I implemented the multiple virtual screen concept for the old Andrew window manager. After several years of working with this system, I have found the following to be a common way of using the system: Over the course of a day, I use the computer system for several unrelated tasks. Each task might require several windows simultaneously. For example, a simple programming task might require an editor window on the program, a shell window for compilation and program execution, and a window to display the output of the program under development. All of these windows are needed at the same time and should be tiled to allow easy and immediate access.
A more complex programming task might require several editor windows on several related program files, windows displaying help information about system calls and libraries and several output windows to allow the current output to be viewed and compared with previous program outputs. Another task might be reading system bulletin boards with additional windows to send and read mail. Electronic mail often requires several windows since a mail inquiry may require searching through the file system to find relevant information for the reply.
In general, each task requires a set of windows. The tasks partition the complete set of windows for a user. Thus the tasks of a user define a partition of windows into window sets.
The set of windows for a particular task may change, over time, as new windows become necessary for a task, are used, and eventually are no longer necessary and are deleted. However, windows seldom move from one task set to another, in my experience. Occasionally, a window which is part of one task set may become the center of a separate task (a large sub-goal or digression from the original task) and may then result in the creation of a separate set of windows for this new task.
Since each window for a particular task is necessary for that task, the windows within a window set should be tiled. However, the window set of one task is unrelated to the window set of another task, and since the user can only direct attention to one task at a time (with relatively infrequent and obvious switching between tasks), separate window sets can be overlapped.
Tasks may be long-lived or short-lived. I may be working on several projects at a time (working on a program, writing a technical paper, preparing class notes, reading mail or news -- which tends to spawn many short-lived tasks -- and so on), so I may have several window sets at a time. Some window sets last for weeks while others are created, used, and deleted in minutes.
In the extremes, this layout model includes both traditional tiled and overlapped systems. If all windows are in the same window set, the layout is completely tiled. If each window is in its own window set (a singleton set), the layout can be completely overlapped.
With multiple virtual screens, each virtual screen can be used to hold one window set. Switching between window sets requires switching between virtual screens. This can be easily done with either mouse or function keys.
The concept of ``window sets'' and multiple virtual screens that we are using here is similar to the ``Projects'' concept of SmallTalk [Goldberg 1984] or the ``Rooms'' concept from Xerox Parc [Card and Henderson 1987].
The modification of the X11R3 sample Sun server to support multiple virtual screens took about a week of programming time. Much of this was in finding the affected data structures and code. The modification was then fairly straightforward.
The major data structure that needs to be changed is screenInfo. This data structure contains a description of each screen which the server is supporting. For the Sun code, it is initialized by calling InitOutput which calls each of sunBW2Probe, sunCG2CProbe, sunCG3CProbe, and sunCG4CProbe. These routines each search for their particular display. If they find one, they call AddScreen which calls <display-type>Init. The result of this autoconfiguration is the data structure screenInfo has a number of screens screenInfo.numScreens and an array screenInfo.screen of screen descriptors.
Our first set of changes was then,
While the initial implementation of multiple virtual screens for X11 was usable and demonstrated the relatively simple changes needed, a number of generalizations were immediately apparent to allow a user to tailor the system to his or her own style of use.
A more important issue with the use of multiple virtual screens with the X11R3 system is the poor support for multiple screens provided by the available window managers. It appears that each screen must have its own window manager and windows cannot be moved from screen to screen. This is true for both multiple physical screens and multiple virtual screens.
We have modified the Sun sample X11R3 server to provide multiple virtual screens on a color display. Our implementation uses the color map to select and display a particular virtual screen. This provides very rapid switching from one virtual screen to another, and allows up to 8 different virtual screens on each color display, using each of the 8 bit-planes in the color display as a separate monochrome virtual screen.
In general, it would be possible to break an 8-bit color map up into a number of colored virtual screens also. For example, one 8-bit color map could provide:
We have reported on modifications which we have made to the X11R3 Sun server to allow multiple monochrome virtual screens on a color display. This particular change was possible because of the generic monochrome driver support code for X11R3 and the flexibility of memory mapping for the Sun color display. Our server demonstrates the practicality and usefulness of multiple virtual screens.