Jump Over Left Menu
9. A Graphics Standards View of Screen Management
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 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.
9.3 INTERFACE TO GKS
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:
- FMS receives graphical output defined in bitmap coordinates but unclipped. The FMS performs the necessary clipping. Note that for efficient implementation of GKS, the clipping rectangle should be specified independently of the frame boundary.
- FMS receives graphical output defined in bitmap coordinates and clipped so that all output is known to reside within the boundary of the frame.
9.4 SUBDIVISION OF FRAMES
Some existing FMSs (for example, TooiKit/32 ) provide facilities for controlling subareas of the complete frame. Two concepts have been introduced:
- Panels: it is assumed that the application program has the ability to divide the complete frame into one or more panels with each panel giving a view of an object to be displayed. Control is provided for scrolling and adjusting the view of the object.
- Panes: a panel can be divided into a number of panes. Each pane can contain a different view of the object.
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.
9.5 ASPECT RATIO AND POSITIONING WITHIN A FRAME
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.
9.6 OUTPUT CONTROL
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:
- Output need not be visible on a specific workstation: an example could be the case of output being sent frame by frame to a plotter with the operator having the ability to view selected frames on another device to check accuracy of production. This is achieved in the graphics standard by having the ability to activate or deactivate particular workstations.
- Output must be generated but timing is unimportant: in GKS, a workstation can be put into the mode ASTI (At Some TIme). This allows the workstation to batch updates until an appropriate time occurs to output it (useful in the context of a plotter).
- Output must be up to date on workstation before next interaction: in GKS, a workstation can be put in the mode BNIL (Before Next Interaction Locally). This recognizes that input should only be accepted at a workstation if the view on that workstation is up to date.
- Output must be up to date on all active workstations before next interaction: in GKS, a workstation can be put in the mode BNIG (Before Next Interaction Globally). This recognizes that input should only be accepted at a workstation if the views on all the active workstations are current.
- Output must always be up to date as soon as possible: in GKS, the mode ASAP (As Soon As Possible) requires output to be sent to all workstations as soon as is possible.
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:
- If generation of output is time consuming, it is still sensible to stop output to a frame when it is not required.
- A workstation working in ASTI mode assumes that either the operator sees the output or it is recorded in a permanent media. This mode has little use in the 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.
- The ASAP mode implies at least that the virtual frames are updated as graphical information is output.
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:
- to output to a virtual frame;
- to force output to be current on a visible frame;
- to force output to be current on all frames owned by an application before the next interaction;
- to force output to be current on the current frame before the next interaction;
- to support a mode whereby all graphical output is made visible. This could be by a switch which requires output on a frame to be made visible before the frame is cleared and another displayed.
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:
- VALUATOR: could use a separate temporary frame to input the value;
- CHOICE: pop-up menus could be used;
- STRING: echoing of input need not be in the current frame.
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:
- LOCATOR tracking: it must be possible to echo the current position of the mouse.
- Rubber band lines: it must support a rubber band line from a specified point to the current position of the mouse.
- Highlighting: of current CHOICE being pointed at followed by feedback of CHOICE selected.
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:
- Process creation: an icon is used to represent a dormant process. Picking the icon effectively causes a frame to be created and the relevant process started. It can be regarded as a macro facility for frame creation and process start-up.
- Virtual frame identification: obscured frames or ones completely off the screen can have an icon associated with them which can be used to make the frame visible.
- Process status: an icon is used to signify the status of a frame not currently visible. It might give information such as whether a process has completed, is waiting for input etc.
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.
- The FMS should control information displayed on a single bitmap screen.
- The FMS is responsible for the management of a set of frames several of which can be associated with a single application.
- The FMS must know which frames are associated with the same application.
- Frame creation must be possible from the application program.
- Graphical primitives should be passed to the FMS in frame coordinates.
- Either the frame is in the memory of the workstation and it is responsible for bitmap updating, or the FMS must be capable of handling GKS primitives at the workstation level.
- If clipping is provided by the FMS, it should be to a specified boundary rather than the boundary of the frame.
- No subdivision of frames is necessary. Any requirements of this type should be handled by the graphics system or the workstation.
- The aspect ratio of output is defined by the application and not the FMS. Changes in frame size must be reported back to the application if any effect on the output is expected.
- An FMS should work in ASTI mode. Conceptually, virtual frames are updated as the output appears.
- The FMS should be able to indicate to the operator that input is required and in what mode from which logical device.
- The FMS should be capable of providing logical input in all three modes and from all six logical input classes. The separation of tasks between the workstation and FMS could vary.
- The FMS should support input from a keyboard with the ability to send an event report when end of string is indicated.