Presentation space management and viewporting on a multifunction virtual terminal

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to an interactive display system of the kind having a refresh raster or matrix addressed display device and incorporating a `windowing` process by which means specified portions or `windows` of application data may be selected and transformed to be displayed in a predetermined region or `viewport` on the screen of the display device.

2. Description of the Prior Art

Such interactive display systems are well known as can be verified by reference to standard text books on the subject such as "Principles of Interactive Computer Graphics" by Newman and Sproull, 2nd Edition 1979 and "Fundamentals of Interactive Computer Graphics" by Foley and Van Damm 1982. In these text books the term `world coordinate system` is used for the space in which the picture specified by the application is defined, and the term `viewing transformation` for the transformation that converts this picture into screen coordinates. The world coordinate system is chosen to suit the application program whereas the screen coordinate system is inherent in the design of the display. The viewing transformation forms a bridge between the two and in general allows any desired scaling, rotation, and translation to be applied to the world-coordinate definition of the picture. The less general case, in which no rotation is applied by the viewing transformation is called the window transformation.

The windowing transformation is so named because it involves specifying the `window` in the world coordinate space surrounding the information required to be displayed. In addition to the `window`, a `viewport` or region on the screen in which the `window` contents are to be displayed can be defined. Generally speaking the viewport is a rectangle on the screen and may correspond to the full screen dimensions but is often considerably less. By using a viewport smaller than the full screen, room is left for other data such as menus, text messages each of which may be displayed in its own separate viewport.

In this terminology, the window is used to define what is to be displayed and the viewport specifies where on the screen it is to be displayed. Such scanning systems enable a user to perform a variety of operations, for example scanning over a large picture keeping the window size constant and varying its position with respect to the larger picture or changing the picutre magnification by changing the window size but keeping the viewport size constant. Techniques for performing these windowing transformations involving such programming devices as clipping algorithms, for example, are not regarded as forming part of the present invention and since such techniques are adequately described in the aforementioned text books and well known in the industry, detail of their implementation is not regarded as being necessary to the understanding of the present invention to be described herein, and consequently will not be given.

SUMMARY OF THE INVENTION

The present invention is concerned, not with the specific details of converting the data from coded form in which it is generated or received, to non-coded form for display, nor with the mechanism for performing the transformation from specified windows to viewport, but with the particular system management and control programs which control the movement and storage of application data within the system in such a way that the application progresses are, to all interests and purposes, totally independent of the real display system.

Data generated by or supplied to a system in the course of the performance of an application (text, graphics, image or mixtures of all three) is generally in the form of coded display lists. Thus, during performance of a text application, textual information as entered for example from an input keyboard by a user may be accumulated as lists of EBCDIC or ASCII characters. During a graphics application, the individual lines constituting the graphics picture may be held as lists of vector orders.

In one system exemplary of the state of the art the application program itself performs all the operations on the application data needed during performance of the application. Thus the application program formats the application data to the specific lay-out required on the screen for display of a selected window in a defined viewport. This formatted information is then copied in the screen refresh buffer as a mapped representation of the data as it is required to appear on the screen. Should the position of the window relative to the application data change, for example during scanning of the window over the more extensive application data, or when the dimensions or location of the viewport on the screen change, or a new window on the same or different application data is requested, or when an existing window is deleted, then in each and every case, reference is made back to the associated application program, the formatting procedure required as a result of the changed circumstances is re-executed and the new formatted data copied in place of the old in the refresh buffer. Clearly interactive processes performed by a user at a terminal such a moving a viewport on the screen or moving a window over the application data impose considerably processing demands on the CPU running the application program. Often the process cannot be performed at the required rate resulting in time delays, probably blanking of the screen, and general dissatisfaction of the user. The problem is aggravated with those systems in which the terminal does not have in-built processing power, or only little processing power, and relies on a CPU in a remote host for all or most operations.

U.S. Pat. No. 4.070,710 describes a computer graphics display system which alleviates the problem to some extent by formatting data supplied from a host CPU within a terminal system itself and storing the formatted data on a bit-per-pel basis in a random access memory of the terminal. The capacity of the random access memory exceeds the display area of the screen and a control unit for the display selects portions of data stored in the RAM for display in pre-determined regions on the screen.

The problem with this arrangement is that the information available for display on the screen in limited to that which can be selected from the data stored in the random access memory. Thus, although the information content of this RAM exceeds that of the screen, in practical terms, it does not give the user much freedom of action. In the event that a user wishes to display information on the screen not contained in the ramdom access memory, then the required information must be accessed from the programmed host computer, formatted and written in mapped format into an allocated region of the random access memory.

In contrast, an interactive display system in accordance with the present invention completely overcomes the problem by providing sufficient presentation space storage for the terminal, either real or virtual, to provide for on-demand storage and retrieval of bit image representations of all the data formatted by the application or applications invoked by the user (whether or not such bit image representations are or will be displayed). The screen manager has access to this data and is operable in response to user input to identify and map the contents of those presentation space storage locations containing the selected windows of data into the identified viewports on the screen. In order to make economic use of the available presentation space storage, space is only allocated when the applicaion program presents non-null data for display. Furthermore, as a part of presentation space becomes available during use, as a result of the display list being changed by an application program for example, it is recovered to be re-allocated as required.

In order that the invention may be fully understood, a preferred embodiment thereof will now be described with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic representation of a portion of an interactive display system according to the invention;

FIG. 2 shows various presentation space and viewport options;

FIG. 3 shows presentation space storage allocation and virtual symbol storage allocation on the virtual memory terminal;

FIGS. 4a, 4b and 4c shows the procedure for the definition of a current viewport;

FIG. 5 shows the flagging technique used for overlapping viewports;

FIGS. 6A, 6B, 6C, 6D, 6E and 6F show the procedure for deleting a viewport from a screen of overlapping viewports;

FIGS. 7a and 7b show two scrolling implementation options;

FIG. 8 illustrates the technique for symbol storage free list allocation and build;

FIG. 9 illustrates the use of presentation space index segments;

FIG. 10 illustrates presentation space tracking with cell data;

FIG. 11 illustrates presentation space tracking with pel addressed data and cursor tracking; and

FIG. 12 illustrates the technique used for symbol storage cell recovery.

DETAILED DESCRIPTION

FIG. 1 shows a schematic representation of a portion of an interactive display system according to the invention implemented on a virtual memory terminal (VMT) system such as is described in the European Patent Application No. 43391 published on Jan. 13, 1982 (U.S. Ser. No. 276,771 filed 6/15/81 and assigned to the assignee of this application).

Coded source data generated for example by the system in the course of the performance of one or more applications (text, graphics, image or mixtures of all three) invoked by the operator of the VMT system are held in bulk storage 1 as coded display lists where they are available for access by the operator on request. As stated previously, the display lists may contain lists of EBCDIC or ASCII characters for alpha-numeric applications or lists of vector orders for graphics applications.

Presentation Interface Services 2 operate in conjunction with the VMT Store Manager 3 in response to an operator request for a selected application to allocate and load formatted data produced from the associated display lists into available storage 4 of the VMT. (The VMT storage may include real and virtual storage locations and is shown bounded by a chain dotted box).

The formatting procedure is quite conventional and does not form part of the present invention. Although formatting is performed by the application, in the schematic representation of the system shown in the FIG. 1, it is convenient to show the display lists being processed by an independent formatter represented by block 5.

As fully explained in the aforementioned VMT patent application, data loaded into VMT is fed into a dynamically managed region of random access store of the VMT under control of primitive microprocessor control instructions permanently held in read-only storage. Records copied to a region are contiguously stored as segments in successive free storage locations and are chained together for subsequent access in a plurality of double-threaded chains. The VMT store manager 3 controls the necessary functions to CREATE, MODIFY, and DELETE segments as required by the application and provides for store-through of segements of RAM to a backing store and main store. The store manager also identifies segments within RAM available for deletion from RAM on a least-recently-used basis to provide additional space for new segments.

It is seen therefore that during operation of the system where the operator may wish to display data from one or more applications, the segement containing the associated display lists of application data and the segments containing the formatted representation produced therefrom may become widely distributed throughout real and virtual storage 4 of the VMT. However, for the purposes of the understanding of this invention the storage locations allocated for a formatted representation of application program display data, although in practice possibly dispersed throughout the storage, may be regarded as being a contiguous block of multiple storage locations within the general storage area 4 as shown in FIG. 1 and referenced Presentation Space (PS) 1, PS2 . . . PSN. Once a display list has been accessed by the application, then the presentation interface services places the entire formatted representation in an allocated presentation space within storage for subsequent access by the screen manager to be described hereafter. The parameters which specify the dimensions of each presentation space are supplied by the user application and then the necessary physical storage space is allocated by the presentation interface services without the further involvement of the application. In the design described the total number of concurrently activated presentation spaces is not logically limited but in practice, the field size allocated to the presentation space address may provide a practical limit. This loading of entire formatted representation of application program display data into allocated presentation spaces completes the first phase of the operation of the system.

The second phase of the operation involves the loading of selected portions of the various formatted representations occupying the presentation spaces to a refresh buffer 6 under the control of a screen manager 7 responding to user input instructions. The refresh buffer 6 is mapped buffer such as is used in the IBM (Registered Trade Mark) 3277, 3278, and 8775 display terminals in which, the character or symbol codes or pointers are stored at positions within the buffer corresponding to the display position on the screens. A character/symbol generator 8 contains the acutal bit patterns representative of the different characters or symbols to be displayed. For alpha-numeric characters and some commonly used graphics symbols the corresponding bit pattern cells are permanently held in a read-only section 9 of the character generator 8. During display of a graphics picture for example where bit patterns representing portions of lines are required the cells are initially created and held in assigned locations of virtual storage 10 and copied to a read/write section 11 of character generator 8 when the corresponding symbol code is loaded into the buffer 6. Further details of this part of the operation will be given elsewhere in this specification. During refresh, a raster scan refresh mechanism 12 reads the characters and symbol codes sequentially from the buffer 6 which is sufficiently large to be able to store one character/symbol code or pointer for each character cell on the screen 13. The codes act at pointers to the various bit patterns stored in the character/sumbol generator 8 which are accessed and sent to the screen 13 in a conventional manner.

The viewpoint dimensions and viewport screen positions used to view the contents of a presentation space are determined interactively by the user. Viewport overlay is provided to enable sections of multiple viewports, whose aggregate total areas exceed the total screen area, to be viewed concurrently. Thus in FIG. 1 the buffer 6 contains portions or windows 14.1, 14.2, 14.3 respectively of presentation spaces data contained in windows on presentations space PS. 1, PS.5 and PS.3. This data is subsequently displayed on the screen 13 in correspondingly overlaying viewports 15.1, 15.2, 15.3 as shown.

Thus in response to a user requesting display of data contained in window 14.1 of presentation space PS.1 in viewport 15.1, the screen manager 7 operates to copy the appropriate formatted display data contained in window 14.1 into block 16.1 of storage refresh buffer 6 in the locations defined by the position of the viewport 15.1. If thereafter the user requests display of data contained in window 14.1 of presentation space PS.5 in viewport 15.1 which partially overlays viewport 15.1 then the screen manager 7 operates to copy the appropriate formatted display data contained in window 14.1 into 16.2 of storage in refresh buffer 6 with deletion of the underlying portion of data in block 16.1. Finally, if the user requests display of data contained in window 14.3 of presentation space PS.3 in viewport 15.1 which partially overlaps viewport 15.2, then the screen manager organizes the copying of the data from window 14.3 into block 16.2 of storage with consequential deletion of the underlying data in block 16.2.

In broad outline therefore, the invention is seen to consist of two major mechanisms: (1) the presentation interface services 2 which controls the allocation of presentation spaces for the formatted representations produced from application program coded display lists. (The execution performance for decoding the display lists is much reduced with this implementation as the whole to the display lists is decoded into the presentation space only infrequently.) (2) the screen manager 7 which operates in response to user interaction to transfer selected areas of the presentation space to a viewport or the movement of viewport content to new viewport positions or a combination of both. The trading of increased storage for improved execution performance matches the characteristics of a low-cost terminal but it can be excessively costly in storage if the storage allocation of the terminal is inefficient. For these reasons the invention is ideally suited for implementation on a virtual memory system.

PRESENTATION INTERFACE SERVICES (2)

The presentation interface services contain a set of presentation space instruction which enable the allocation and de-allocation of presentation spaces and the specification of presentation space dimensions and type.

The presentation interface provides both a pel and a cell addressing option in all presentation spaces. Cell addressing is intended for alpha-numeric and text display and has a top-left addressing origin. Pel addressing is intended for graphics, image and character string display and has a bottom left addressing origin. Thus the two addressing systems for the screen identify respectively row-column position for character data where (0, 0) lies at the top left of the screen, and (x, Y) coordinates for graphic data where (0, 0) lies at the bottom left of the screen. For compatibility with the hardware structure ofthe IBM 8775, presentation space cell addressing on VMT is predefined to use cells each consisting of a matrix of 9.times.16 pels. Presentation space dimensions are requested as an integral number of character cells. With this arrangement, when test is being entered for display it appears initially at the top left of the presentation space and moves progressively across and down the screen in the accepted manner. Conversely when graphic data is entered it appears initially at the bottom left of the presentation space and grows progressively across and up the screen.

Each presentation space allocated is given a unique serial number which is subsequently used by the application to select it for data read or write. It is necessary that the integrity of the presentation space serial numbers is preserved by the system procedures to prevent an application accessing a presentation space, or presentation spaces, which have been allocated to another application.

FIG. 2 shows typical presentation space and viewport options. Application No. 1 is a directory of the current allocation of presentation space. Application No. 2 shows an option where multiple presentation spaces have been requested. Application No. 3 shows an option where multiple viewports access a single presentation space. Appropriate cursor symbols are shown associated with the viewports.

Referring to FIG. 1 and FIG. 3 presentation space entries can point either to the read-only section 9 of the character generator 8 or to the read/write virtual symbol storage 10. The most commonly used symbols such as alphanumerics are permanently held as character cells in ROS 9 and the less common symbols such as portions of lines generated by the application are loaded as graphics cells into virtual symbol storage 10 as and when they are generated by presentation interface services. In practice, the 8775 hardware on which VMT is modelled has eight sets of real symbol storage in which characters or symbols are either permanently held or into which they may be loaded. Each set can contain 192 cells. Two sets 0, 1 are used only in read-only mode and permanently hold the standard symbols such as alpha numerics, and those graphics symbols most commonly used such as horizontal and vertical straight line segments.

A previously allocated entry in a presentation space row is converted from referencing a ROS symbol storage cell to referencing a RAM virtual symbol storage cell is pel addressed data is overlayed onto cell addressed data. To prevent loss of data in this instance, the original ROS cell contents are copied to RAM virtual symbol storage. When cell addressed data is overlayed onto pel addressed data then the content of the newly requested ROS cell is OR-ed into the previously allocated RAM virtual symbol storage cell.

Allocation of presentation space in VMT will now be described with reference to FIG. 3 of the drawings. Following a user request for a selected application, a pointer PTR 1 (say) associated with the selected application 1 (say) is loaded as a list header in a location of VMT RAM specifically set aside for the purpose. As each additional application is called, so different identifying pointers (PTR 1, PTR 2, PTR 3 . . . ) are allocated and added to the application list 17. Presentation space within VMT storage is allocated by the VMT store manager a row at a time as it is required. Thus the header pointer PTR 1 (say) for an application points to an associated space segment 18 containing further pointers to the actaul rows allocated within the RAM and constituting the presentation space for the application. These row pointers RPTR1, RPTR2, RPTR3 . . . are assigned as each row is required. Accordingly, the space segment (or segments if more than one is needed) contain as many row pointers as there are rows of presentation space required by the application, which number can greatly exceed the number of rows available on the screen for display.

Each row pointer RPTR1, RPTR2 . . . points in turn to a second level row segment 19 of the presentation space each of which contains a reference to the actual cells allocated for that row. Each column field in the row referencing a cell three sub fields and selects: (1) a cell set; (2) a character code within the set, and (3) a flag field.

The symbol storage cell segments contain the actual 9.times.16 bit patterns for display on the screen and fall into the two categories namely ROS or RAM referred to hereinbefore. Set 0 segment and Set 1 segment hold the permanently written ROS cells (shown schematically as block 9 in FIG. 1). Only two ROS segments are shown in FIG. 3 although of course more may be provided if required. The remaining cells containing bit patterns generated by the application using for example Bresenham algorithms are loaded as they are generated into a number of further segments identified as Set n segment to Set n+3 segment in the figure in the virtual random access storage of VMT (shown schematically as block 10 in FIG. 1). Thus the entry for each column field in a row segment contains the identification (set segment number and character code) of the character or symbol of presentation space data associated with that row and column position.

The character code identifier specifies a symbol storage cell number in the selected symbol storage set. The flag byte indicates whether the symbol storage cell referenced by the column entry is in real storage 9 or in virtual symbol storage 10.

Thus in the figure, row pointer RPTR 2 points to its row segment in RAM which in turn points to the appropriate symbol storage cells in that row. From the figure it is seen that the second column entry of row segment 19 points to the 2nd cell within the Set n+1 segment 19 and the fact that this is virtual symbol storage is indicated by the flag byte being set to binary `1`. The third column entry of row segment 19 points to the 3rd cell within the Set 0 segment and the fact that this is read symbol storage is indicated by the flag byte being set to binary `0`. Each presentation space cell is 18 bytes long and there are 56 cells in a set in the present embodiment.

The benefit of this presentation space structure is in the storage economy that can result from only allocating presentation space row and bit storage to the occupied areas of a presentation space. A request for a new presentation space allocates a space segment which is initialized with all its row pointer fields set to null. Row segments are allocated when data is to be entered into them to ensure that row storage is allocated only where it is required. When a row segment is allocated its column entries are set to null. Thus the allocation of a row segment to a presentation space does not allocate image storage for the row. Data entry into a presentation space which is in pel addressed mode causes cells to be allocated from the 56 byte RAM virtual symbol storage cell sets to the column positions in row segments which are to contain data. This ensures that the image storage is only allocated in the column positions where it is required. On demand allocation of the virtual symbol storage cells ensures that a maxiumum of one virtual symbol storage cell set remains unallocated at any time.

Due to the large capacity backing store available on VMT the overcommitment of terminal storage by large or non-sparse presentation spaces does not result in termination of applications or inhibit the generation of additional presentation spaces. Overcommitment of terminal storage may cause presentation space access degradation due to paging and thus affect application execution performance or operator function response. If the terminal store is of adequate size to hold the presentation spaces which the operator or applications require to access concurrently, then paging will occur only when the working set changes as a result of viewport reselection or activation of a different application.

A CLEAR presentation space facility invoked by the presentation space services retains the space segment for the presentation space and reinitializes its referenced row segment pointer fields to null. The previously allocated row segments are freed and the virtual symbol storage cells referenced from the row segments are cleared. Thus the storage space previously allocated to the presentation space is made available for re-use.

A DELETE presentation space facility invoked by the presentation space services is similar to a CLEAR presentation space with the addition that the space segment is also freed. A presentation space is not deleted while it is still accessed by viewports.

This completes the description of the allocation of presentation space for the application data. The specific techniques involved for allocating virtual memory space for the data under program control are themselves not new being the same as those used in VMT or other known storage management systems.

VIEWPORTING FACILITIES

The screen manager includes a viewport management program which is used to develop the viewport operations provided to a user of VMT in order to view multiple presentation spaces. The viewport operations provided to the terminal operator include DEFINE, RESELECT, MOVE, REDIMENSION and DELETE. These operations largely involve standard techniques such as described in the aforesaid standard works of reference "Fundamentals of Computer Graphics" by Foley and Van Damn and "Principles of Interactive Computer Graphics" by Newman and Sproull. Since these techniques for defining and transforming viewports on a screen are extremely well known and understood by persons skilled in this particular art and because a detailed understanding of the techniques is not required in order to understand and appreciate the present invention, details will not be given herein. Instead, a summary of the viewport operations are given with those features and details which have been specifically selected or devised for this particular implementation on VMT explained.

VMT viewports are specified by their top right and bottom left screen pel coordiantes however their usable area is limited to the integral cells contained within the specified rectangular areas. Viewport coordinate definition is performed using a graphics cursor which is provided by the presentation interface. Any one of a number of specified viewports can be selected as the current viewport and will be the one which will be brought to the foreground by being redrawn to overlay any other viewports. Only the current viewport displays a cursor or is scrollable.

Each presentation space must have one, and may have many, viewports allocated to it as is shown in some of the examples in FIG. 2. Each viewport is given a unique serial number and a permanent logical link is established with the presentation space from which its formatted display data comes. In this implementation a viewport cannot be reassigned to an alternative presentation space. If the application executing is the one being viewed through the current viewport then all presentation space updates are viewable as they happen. All viewable fragments of overlayed viewports must be updated directly their underlying presentation spaces are modified. The number of viewports which can be synchronously updated is dependent on the size of the viewport identification field that is assigned to the screen buffer.

When a new viewport is requested, in this case by a DEFINE operation, it is initialized to cell addressed mode. That is, the alignment of the presentation space to the viewport is initialized so that the top left of the presentation space registers with the viewport top left and an alphanumeric cursor is displayed in the viewport top left. The pel addressed mode parameters for a new viewport are initialized so that when this mode is first selected the presentation space bottom left will register in the viewport bottom left and the graphics cursor will display in the viewport bottom left. A newly requested viewport is automatically initialized as the current viewport. If a requested viewport dimension exceeds the corresponding dimension of the underlying presentation space then the viewport dimension is automatically truncated to match the presentation space dimension. In this event the top left view port coordinate is retained as requested.

The current viewport can be scrolled over the presentation space by cell increments. Attempts to scroll to positions where a presentation space boundary would like within the viewport boundary inhibited. A typamatic scrolling over both cell and pel based presentation spaces has been achieved.

Each viewport is allocated its own unique alphanumeric and graphic cursors. A selection of cursors are shown in the viewports in FIG. 2. These can be independently moved over their associated viewport and used for alphanumeric and graphics entry to the underlying presentation space. Data can be entered into a presentation space from any viewports associated with it. The current viewport can be toggled between the cell and pel addressed mode. In cell addressed mode the alphanumeric cursor is displayed, in pel addressed mode the graphic cursor is displayed. The registration of the cursors to the presentation space is preserved between modes allowing the previous data entry status in either mode to be reselected. The graphic cursor shape for each viewport is selectable by the terminal operator to aid viewport identification. Full clipping of graphics cursors occur when a cursor encounters its viewport boundary. The relative position of cursors with respect to the displayed presentation space is retained during scrolling. If a cursor would leave the viewport as a result of the scrolling action then its X and Y presentation space address is modified to keep it within the viewport.

The current viewport can be repositioned to any position on the screen using the MOVE operation. The registration of the viewport to the presentation space and the registration of the presentation space to the current cursor position are retained unaltered by this move. The repositioning operation can be executed with or without viewport redimensioning. When a REDIMENSION operation is used the registration of the presentation space to the viewport is reinitialized as for a new viewport (i.e. top left to top left for the cell address parameters, bottom left to bottom left for the pel address parameters). It has been found necessary to reinitialize the alignment of the presentation space to the viewport during viewport redimensioning due to the possibility that the new viewport dimensions are incompatible with the current presentation space scroll position. The currently selected addressing mode for the viewport is unaltered by redimensioning.

A viewport RESELECT operation deselects the current viewport and installs the requested viewport as the current viewport. Viewport reselection automatically recreates the total viewport status and data content prior to deselection plus any changes which have occurred in the viewable content of the presentation space since deselection but were previously overlayed. The current is redisplayed in a reselected viewport at its position prior to deselection or, if data entry to the underlying presentation space had taken place while deselected, at the next data entry point.

The DELETE viewport facility reselects the viewport to be deleted as the current viewport then deletes the current viewport and leaves the screen without a current viewport. It then invites the oeprator to select the next current viewport. A presentation space is not allowed to exist without having a viewport to reference it. When the last viewport referencing a presentation space is deleted then the presentation space which it references is also deleted.

The deletion of the current viewport and its contents clears the current viewport screen area and thus often provides an opportunity to extend previously overlayed viewport fragments. To take advantage of this situation it is necessary for the operator to reselect the viewports to be extended unless a sequential history of selection is retained which would allow this to occurr automatically.

VIEWPORTING IMPLEMENTATION

The presentation interface viewport instructions are implemented mostly in low level code and perform the screen functions necessary to support the viewport manipulation operations required by the viewport management program. These instructions are used by the viewport management code to provide the viewport specification and manipulation functions required by the terminal operator to view presentation spaces.

Cursor vectors drawn by the presentation interface are clipped at the viewport boundaries and graphic cursors are consequentially not visible outside the current viewport. As it is desirable to set viewport coordinates interactively using the system graphics cursor an ERASE-CURRENT-VIEWPORT instruction is provided to give the system graphic cursor full screen access for this purpose. This instruction sets the screen mode so that full screen access is available to the system cursor which is then used for defining viewport coordinates.

The top left and bottom right coordinate for the single current viewport are held below the presentation interface level using a SET-CURRENT-VIEWPORT instruction. This level of the interface provides facilities for drawing the current viewport from the coordinates (DRAW-CURRENT-VIEWPORT), in a chosen line style, such that the viewport is the enclosed area specified by a rectangle constructed from the coordinates.

The inverse of the viewport can be selected to make the area between the