LogoMethodology of Window Management

Jump To Main Content

Jump Over Banner

Home

Jump Over Left Menu

Window Management

Overview

Preface

Acknowledgements

Participants

Contents

1 Introduction

2 Unix

3 Comparison

4 Ten Years

5 SunDew

6 Issues

7 Modular

8 Standards

9 Standards View

10 Structure

11 Partitioning

12 Low-Cost

13 Gosling

14 Issues

15 API WG

16 API WG

17 UI WG

18 UI WG

19 Arch WG

20 Arch WG

21 API Task Group

22 Structure Task Group

23 Future

24 Bibliography

25 Acronyms

Return

This site is best viewed using a browser with either native SVG support or an SVG Plug-in

Access Key Details

10. Windows, Viewports and Structured Display Files

Colin Prosser

10.1 INTRODUCTION

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:

  1. Should the window to viewport mapping be explicit?
  2. Should more than one source space be permitted per windowing system?
  3. Should more than one destination space be permitted per windowing system?
  4. Should many window to viewport mappings be permitted per source?
  5. Should clipping of output to a window boundary be mandatory or under application or user control?
  6. Should it be possible to constrain a particular window to viewport mapping such that it depends on another window to viewport mapping?
  7. 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 )?
  8. Should viewports be permitted to overlap?
  9. Should overlapping viewports mutually interfere?
  10. 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?
  11. Should the inverse window to viewport mapping(s) apply to input?
  12. Should window to viewport (and inverse) mappings be restricted to unique pairs of window and viewport?
  13. Should input events outside those window to viewport mappings directly accessible to an application be detectable by that application?

  14. 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:

    1. repositioning of the viewport on the display surface;
    2. scrolling or panning effects by moving the window in the logical display space;
    3. scaling or resizing of the displayed image;
    4. 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.

  15. Should applications be permitted to manipulate window to viewport mappings independently of any user facility for doing so?
  16. Should it be possible to position viewports partially off the display surface?
  17. Should control over the visibility of windows be permitted?
  18. Should there be some mechanism for notifying applications of the status (or changes to the status) of window to viewport mappings?
  19. Where should responsibility lie for update of images in the destination space?
  20. Should it be possible to specify viewports in alternative destination spaces (eg: printer, remote screen across a LAN)?
  21. For bitmap images, should the window to viewport mapping only map pixels one-for-one?
  22. Should there only be one style of presentation for manipulating window to viewport mappings?
  23. 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.

Issues