Jump Over Left Menu
10. Windows, Viewports and Structured Display Files
Here is a selection of issues for consideration by anyone interested in discussing the merits of making more explicit use of the traditional graphics concepts of windows and viewports, and structured display files in windowing systems.
WINDOWS AND VIEWPORTS
Adopting the traditional graphics distinction between a window and a viewport, the former denotes an area in some source display space and the latter denotes an area in some destination display space. The displayed destination image appears to be clipped to lie within the viewport boundary. Some systems, like the currently issued PERQ PNX windowing system, present a window and viewport as one and the same entity. This can be regarded as a special case of one-to-one window to viewport mapping. Initial hiding of the implicit window to viewport mapping does not necessarily prevent later exposure. This approach has the advantage of simplicity and allows deferral of solving any complexities of the more general case. It has the disadvantage that the user is denied, at least in the short term, several potentially desirable facilities made feasible by fuller manipulation of window to viewport mappings.
Examining some of the possibilities for manipulating window to viewport mappings poses some interesting issues:
- Should the window to viewport mapping be explicit?
- Should more than one source space be permitted per windowing system?
- Should more than one destination space be permitted per windowing system?
- Should many window to viewport mappings be permitted per source?
- Should clipping of output to a window boundary be mandatory or under application or user control?
- Should it be possible to constrain a particular window to viewport mapping such that it depends on another window to viewport mapping?
- Should it be possible to specify the destination of a window to viewport mapping to be part of a source (ie: allow hierarchies of window to viewport mappings )?
- Should viewports be permitted to overlap?
- Should overlapping viewports mutually interfere?
- Should output appearing in any viewport be permitted to modify the appearance of the image in another viewport, without the mutual consent of the application(s) associated with those viewports?
- Should the inverse window to viewport mapping(s) apply to input?
- Should window to viewport (and inverse) mappings be restricted to unique pairs of window and viewport?
- Should input events outside those window to viewport mappings directly accessible to an application be detectable by that application?
Should a manipulation to one window to viewport mapping, which has the effect of changing the visibility of parts of the viewport of another unaltered mapping, be a notifiable event to any applications associated with the affected mappings?
As is well known from traditional graphics, manipulation of a window to viewport mapping permits operations such as:
- repositioning of the viewport on the display surface;
- scrolling or panning effects by moving the window in the logical display space;
- scaling or resizing of the displayed image;
- controlling the visibility of a window.
When deciding how or whether to allow these operations in a window management system, several more issues might be considered.
- Should applications be permitted to manipulate window to viewport mappings independently of any user facility for doing so?
- Should it be possible to position viewports partially off the display surface?
- Should control over the visibility of windows be permitted?
- Should there be some mechanism for notifying applications of the status (or changes to the status) of window to viewport mappings?
- Where should responsibility lie for update of images in the destination space?
- Should it be possible to specify viewports in alternative destination spaces (eg: printer, remote screen across a LAN)?
- For bitmap images, should the window to viewport mapping only map pixels one-for-one?
- Should there only be one style of presentation for manipulating window to viewport mappings?
- What makes for a good style of presentation?
10.3 BITMAPS AND STRUCTURED DISPLAY FILES
Given a one-for-one window-pixel to viewport-pixel relationship, it is attractive to consider the source space in bitmap form. One can readily imagine rapid panning and scrolling of a window over a larger display area, without having to recompute the image. Additional measures need not be taken to save information for refreshing the contents of partially obscured viewports when they are later revealed. In practice, optimizations might be made, for instance, to economize on memory utilization by avoiding duplicate copies of unobscured portions of viewports. Given multiple mutually constrained window to viewport mappings, independent images may be combined easily so as to appear in the destination space as if a single image, but with differing areas being potentially under the control of independent applications.
A bitmap image representation has some disadvantages, however. Limitations on physical resources may severely constrain the possible size of a bitmap. Transfer of information among display spaces (cut and paste) is limited to bitmap form which may have undesirable consequences if the resolutions differ. Any structure that may have been used by the application to construct the image is lost so it might be difficult to identify logical components of the image.
Another possibility is to introduce a structured display file. The disadvantage of having only a structured display file is the time taken to regenerate complex images. Perhaps some combination of structured display file and bitmap might be more appropriate than either alone.
- 24. How should display space images be represented? Bitmap, structured display file, combination of both?
- 25. Where should the source space reside? Application or windowing system?
- 26. Should optimizations on bitmap memory utilization be the sole responsibility of the windowing system? Or may it depend on applications honouring requests for display updates?
- 27. Should the windowing system support any structured display file?
- 28. In what form should a structured display file be maintained?
- 29. Should a structured display file be maintained on a per window or per source space basis?
- 30. Should it be possible to transfer information among windows independently of the applications which generated the images?
- 31. Should it be possible to store and retrieve images independently of the applications which generated the images?