Major users of a screen management system will be applications programs written using one of the existing or future graphics standards. The standards will be responsible for the graphical information sent to and received from the screen and its associated input devices. While this will not be the only system requiring access to the screen, it may be useful to identify the constraints placed on a screen manager by the graphics standards, and possible solutions to problems may be sensible in a wider context.
The examples used here will relate to GKS - the Graphical Kernel System [28] - but should be relevant to both PHIGS [6] and GKS-3D [29] also.
The use of the word window in the screen management context is certain to cause confusion in the graphics standards arena. The ISO Graphics Vocabulary and the graphics standards use the word window in the well established window to viewport coordinate transformation paradigm. If coordinates are to be mapped in the transformation pipeline from a higher level (closer to the user) coordinate system to a lower level (closer to the device) coordinate system, the window defines the area in the higher level coordinate system to be mapped on to the viewport, an area defined in terms of the lower level coordinate system.
It is likely that a screen management system will not control just the contents of a viewport but will also control information associated with the viewport including details of how its boundary is to be displayed, possible titles and control points just outside the viewport boundary etc.
To avoid confusion, this paper will use the term frame to describe a viewport on a virtual bitmap screen together with any associated graphical or non-graphical information related to it. The software responsible for organizing the contents of the bitmap screen will be called the Frame Management System (FMS).
The (FMS) is responsible for the control of information displayed on a single bitmap screen. The system allows a number of separate processes to share the screen resources and associated input devices under the control of a single user. The FMS simulates several virtual devices on the single screen where each virtual frame corresponds to a single virtual device. The basic goal of FMS is to allow a single user to interact with several processes at the same time.
GKS is a graphical kernel system which allows a single application to provide graphical interaction with a user in control of one or more real devices. GKS is divided into a virtual and real part. The application is allowed to define output using a variety of coordinate systems which are mapped on to a single virtual coordinate system, normalized device coordinates (NDC). Particular devices map NDC space on to their own device coordinate systems retaining the aspect ratio of the NDC space. This is illustrated in Figure 9.1.
An initial decision has to be made as to where the interaction exists between GKS and FMS in Figure 9.1. The greater part of GKS is concerned with producing and manipulating images created in the NDC coordinate system. It would be difficult for existing GKS applications to work with an FMS above this level. GKS would still need to be responsible for the conversion of application coordinates to NDC.
Assuming the interaction between GKS and FMS occurs below the NDC level, the FMS's role will be to multiplex several GKS workstations onto a single screen from a single application and to multiplex output on a single screen from several applications controlled by a single user.
If we consider a single application and device in GKS, the transformation pipeline is as shown in Figure 9.2.
In GKS, it is possible to clip graphical data at the boundary of the window which is used to transform coordinates from world to NDC. The operation of this clip is delayed with the picture in NDC space being stored as unclipped NDC coordinates together with a clipping rectangle. The reason for this is that it allows this clip to be amalgamated with the mandatory clip against the boundary of the workstation viewport if the hardware can do that efficiently.
The obvious place where the FMS would take over from GKS is somewhere below the workstation window to viewport mapping. The two possibilities are before and after the workstation clip. Because the NDC clip should be efficiently performed by amalgamation with the workstation clip, the two possibilities are:
Some existing FMSs (for example, ToolKit/32 [70]) provide facilities for controlling subareas of the complete frame. Two concepts have been introduced:
It is difficult to fit either panels or panes into the GKS model. Composition of graphical information into a single picture is performed at the NDC level in GKS. Only a single view of NDC space is allowed per workstation. In GKS-3D, multiple views are allowed and correspond in some sense to the panels of ToolKit/32. However, no constraints are placed on the positioning of views in GKS-3D. For example, it is possible for two panels to overlap.
In terms of graphics standards, it is unclear whether an FMS with either panes or panels would have any advantage over one which just treated the frame as the lowest level of subdivision. For the FMS to be responsible for controlling the display of information in panels or panes, the graphics standards would require it to control much more of the viewing pipeline than at present, being responsible for all the workstation functions. In GKS-3D this would require it to do the 3D perspective and viewing transformations.
The graphics standards assume that changes in aspect ratio occur above NDC in the transformation pipeline. A circle in NDC coordinates will appear as a circle on all devices. Consequently, any FMS must have the capability of ensuring no change to aspect ratio in the displayed picture.
Any change of frame size by the operator will require information to be returned to the application program if the picture is to be updated to accommodate the new frame size. It is not the responsibility of the FMS to do this for the application.
The graphics standards assume output is to a device of fixed size (apart from continuous page plotters). It assumes maximum device coordinates for a specific device and allows the application to specify that output should be directed to a subarea of the complete screen. For a virtual device controlled by an FMS, some of this flexibility is probably unnecessary. It may well be sensible for the graphics standard to specify effectively the whole of the viewport as the frame size. There appears to be little advantage in defining the workstation viewport as a subpart of the frame unless output to the frame is anticipated from the application which does not come from the graphics system.
The major reason for sending graphical information to a workstation being used in an interactive mode is to allow the operator to view the output. In an environment with an FMS where the operator is multiplexing several output devices on a single screen, it is quite possible that the operator will not see the graphical output, certainly while it is being generated and possibly ever. This clearly mayor may not make sense in the case of an application using a graphics standard.
The standards recognize that it is possible that a number of situations occur concerning graphical output:
It is sensible to see how these modes of handling frames are mapped for an application running in the context of an FMS and what requirements it places on the FMS.
A sixth possibility exists in GKS but is not particularly catered for. That is where output is being generated and the operator mayor may not be aware of it. An example might be where the output is giving status information. GKS does not differentiate between the two situations.
Commenting on the five modes above in an FMS environment:
The modes BNIL and BNIG effectively require the selected frame or all frames to be visible and current before an interaction takes place.
BNIL mode implies that input can only occur to the selected frame if it is visible.
BNIG is a more stringent mode of operation. In the context of an FMS, it at least requires the virtual frames to be current even if all are not visible.
In both modes, the FMS could save updates to a frame and not apply them as they arrive.
It is clear that if the FMS supports ASAP mode, it satisfies the requirements of the other modes in terms of frames being current but does not really address the visibility issue. Effectively, the graphics standards assume output to be visible.
In summary, the graphics standards require an FMS to have the following capabilities:
Most FMSs will work in an environment where a single keyboard and mouse with buttons will be multiplexed as a set of input devices for each frame.
The graphics standards divide input into six types of logical devices:
Any real input device can be used to simulate these logical devices. A workstation provides the simulation and is required to provide certain types of echoing. In GKS, this echoing must appear on the workstation's screen but not necessarily in the workstation's viewport.
In an FMS environment, the LOCATOR, STROKE and PICK devices must be closely related to the frames controlled by the application. It does not seem unreasonable for the other logical devices to be simulated differently. For example:
Although it would be possible for all the echoing to be done by a workstation sitting on top of the FMS, it is likely that the performance of certain operations can only be achieved effectively if the FMS takes responsibility for echoing. The FMS is likely to need to support:
Input in GKS is available in the modes REQUEST, SAMPLE and EVENT. An FMS must be capable of handling input in all three modes. This may require a particular input device to be switched between logical input devices and different modes as well. GKS also allows more than one logical input to be activated by the same TRIGGER. Thus an FMS should be capable of generating, say, a LOCATOR input and a CHOICE by a specific button hit on a mouse. It is also possible to time input requests and modify the action depending on whether input arrives or not.
Some FMSs provide an icon facility. Its use varies from one to another. Some models are:
In the case of an application using a graphics standard as interface to the FMS, it should be possible for it to run unchanged in the environment of an FMS with icons. GKS has associated with each workstation a Workstation State Table which contains information concerning the workstation. This could be used to contain information such as icon form in case (2) above. In general, I would not anticipate much control of icons being necessary by the graphics application.
The properties of a frame management system suitable for GKS and the other graphics standards should have the capabilities given below.
