WINDOW MANAGEMENT ALGORITHMS
FOR AN
ALL POINTS ADDRESSABLE DISPLAY
by
John Will Webster III
7.'
Submitted in Partial Fulfillment
of the Requirements for the
Degree of Bachelor of Science
at the
Massachusetts Institute of Technology
May, 1983
Signature of Authx__._
Department of Electrical Engineering and Computer Science, 1983
Copyright Q 1983, John W. Webster III
Certified by
fA
Accepted by
u,
//f"~~--'"
Thesis Supervisor
Chairman, Departmental Committee on Theses
Archives
MASSACHUSETTS
INSTITUTE
Or TECHNOLOGY
JUN 1 0 1983
L!RRARIES
WINDOW MANAGEMENT ALGORITHMS
FOR AN
ALL POINTS ADDRESSABLE DISPLAY
by
John Will Webster III
supervised by
Carl E. Hewitt,
Associate Professor of
Electrical Engineering and Computer Science
ABSTRACT
This thesis discusses issues associated with the implementation
The results it presents include:
of window management systems.
an algorithm for updating overlapping windows without consuming
large amounts of memory, a design for multiple-font menus, and a
design for a facility to support a general multiple-font text
formatter on an all points addressable (APA) display.
TABLE OF CONTENTS
Introduction............................
A Word About Windows ...............
3
About JAWS......................... ........................
The Canvas Data Structure.......... .............
.......... 5
The Window Data Structure.......... ........................
5
........................
9
The Window Update Cycle............
.......................
15
The Utility Routines...............
Architectural Benefits............. ....................... 15
Some Inadequacies......................................... 18
Thesis Organization................ ....................... 20
........................ 1
.........................
Chapter 1 -- Screen Management Techniques..
Computation of the Changed Area.......
Screen Management Algorithms..........
The Do Nothing Algorithm.........
Doing Nothing to a Shadow Buffer.
The Fragmentation Algorithm......
....................
22
....................
22
....................
24
....................25
....................27
....................28
Chapter 2 -- Pop-up Menus.................. ....................34
What Should a Pop-up Menu Do?......... ....................34
Implementation Design Issues.............................. 36
Specifying the Implementation......... .................... 39
The Implementation of a Pop-up Menu Canvas ................ 40
Handling Input............................................49
Chapter 3 -- Dynamic Redisplay...................
..............
54
Chapter 4 -- Child Windows .......................
..............
61
Chapter 5 -- Building a Bridge Between POLITE and JAWS
.........
67
.........
67
The POLITE User Interface........................
Entering User Requests into POLITE............... ......... 69
How POPFLAVOR Supports the POLITE Menu System ....
.........
70
.........
71
Mapping Screen Coordinates to Canvas Coordinates.
.........
72
Handling Keyboard Input..........................
Supporting the Document Manager..................
.........
75
The Document Structure and Operations............
.........
75
Mapping a Canvas Coordinate into a Document Coordinate....76
The Benefits of using JAWS with POLITE ....................77
Conclusion..............................................
79
Appendix A -- Display Algorithm Results and Analysis........ ...80
WINTEST1
. ...............................
...87
WINTEST3
.
...............................
...91
QUIXTEST................................
...92
WINTEST4
.
...............................
...92
FIGURES
I.1
1.2
1.3
I.4
1.5
1.6
I.7
1.8
1.9
-
A Typical Window Management System ........................2
The Application, Canvasses, and Windows ...................
4
The Flavor Packages .......................................
6
The Window Hierarchy ......................................
A Surfaced Window
......................................
10
A Buried Window
........................................
11
A Hidden Window
........................................
12
The Window Update Process ................................
14
The DISPATCH Module .....................................
16
1.1
1.2
1.3
1.4
-
The REDISPLAY Algorithm ..................................
23
The "Do Nothing" Algorithm .............................. 26
The Multiple Pass Fragmentation Algorithm ................
29
Complex and Simple Window Configurations .................
32
2.1 - A Sample Pop-up Menu .....................................
35
2.2 - The Structure of the Pop-up Menu Canvas ..................41
2.3 - A Pop-up Menu Entry ......................................43
2.4 - The Correlation Routine for Pop-up Menus .................45
2.5 - The Correlation Primitives ...............................
46
2.6 - The Modified Primitives .................................47
2.7 - The Translation Routine for Pop-up Menus .................
50
2.8 - The Input Routine for Pop-up Menus .......................
52
3.1
3.2
3.3
3.4
-
A Window with a Shared Screen Buffer and Canvas..
........
55
The Background Pattern...........................
........
56
The Basic Pattern-Drawing Algorithm.............. ........ 59
The BACKFLAVOR Translation Routine...............
........
61
4.1 - A Sample Parent-Child Relationship............... ........ 62
4.2 - The Child Window Moves with his Parent...........
........
63
4.3 - Child Window Sharing its Parent's Screen Buffer..
........
64
5.1 - POLITE Uses JAWS to Interact with the APA Screen.
5.2 - The Buffer/Canvas Map as Used by POLITE..........
Al.1
A1.2
A1.3
A1.4
A1.5
A1.6
A1.7
-
........
68
........ 73
WINTEST1 Initially......................................82
WINTEST1 Midway Through........ .........................83
WINTEST1 at End................ .........................84
WINTEST3 Initially...................................... 85
WINTEST3 Moving a Window....... ......................... 86
QUIXTEST................................................88
- WINTEST4.......................
.........................89
TABLES
A1.1 - Screen Management Test Results ..........................81
INTRODUCTION
A WORD ABOUT WINDOWS
In the realm of display devices, we define a "window" to be
on
region
rectangular
a
in
useful
dividing
device through which data is
display
The window abstraction is
viewed and manipulated.
one
physical
and
systems
are software packages
Examples
abstraction.
LISP
machine
window
and,
(Tesler),
thesis,
components (Fig.
their
the
JAWS
JAWS is
(for
management
implement
(Weinreb
system
primary
object
and
system
Moon),
and
which
supports
Smalltalk
A Window System").
is
general-purpose
window
implemented on the PERQ
currently
personal computer, a PASCAL machine with 1MB of
(PERQ),
window
the
our discussion in this
of
application-independent,
an
Window management
existing window systems include the
of
"Jaws
application
more
I.1).
which
particularly
device into several
display
virtual display devices to be shared by one or
programs
a
storage
primary
an all points addressable (APA) display.
One of the essential features of
JAWS
is
its
nature;
general
lack of dependence on application programs allows JAWS to be used
easily
in
application
(O'Hara),
several
programs,
graphic
the
illustrations
for
editor/formatter
applications.
different
this
known
including
a
editor
which
thesis,
and
3270
as
POLITE
Integrated Text Editor)(Borkin and
was
an
(for
Prager),
To
date, several
terminal
used
to
emulator
draw
real-time
integrated
Personal
have
the
been
On-Line
written
This thesis is concerned with the
using JAWS for screen support.
- 1-
I
ADf
T PATTnfl
I
I
Fig. I.1 -- The window management system enables several applications
to share the same physical screen.
-2-
development
of
some
of
the
window
management algorithms and
techniques used in JAWS and uses POLITE to
might
be
used
illustrate
how
JAWS
to support a useful application.
ABOUT JAWS
To begin,
a
summarization
of
the
state
of
at
the
initiation of the work described in this thesis is in order.
The
original
John C.
design
and
basic
JAWS
implementation of JAWS were done by
Gonzalez (as his bachelor's thesis at MIT) and Robert P.
O'Hara of IBM (while on sabbatical at IBM's Cambridge
Center).
A
complete documentation of this effort
in Gonzalez' thesis, Implementing
Display
a
Window
System
is provided
on
an
APA
(Gonz), and should be consulted for details beyond those
which
I provide here.
There are
"canvasses"
two
and
basic
image-containing
"windows"
(Fig.
1.2).
roughly to the "world" of the Core Graphics
in
Scientific
that
structures
in
JAWS:
Canvasses
correspond
Standard
(Siggraph)
they contain the data which is to be manipulated by the
application
program;
Standard's
"viewports"
likewise,
in
windows
correspond
that they "view" (i.e.
to
the
contain the
translated image of canvas data, particular canvasses.
Note that
although a window may view only one canvas at a
there
nothing
time,
is
to prevent several windows from viewing the same canvas.
- 3 -
]<
F is.
I.2
-- The appli cat ion program
v ieLed kb, windols.
-4-
writ. es t
W/ NDOW
canvasses
Lh
hi h are
n
THE CANVAS DATA STRUCTURE
There are several different types of canvasses,
their
representations
them.
The
different
and
collections
in
canvas
types
of
are
routines
type of that
available
canvas
known
underlying
characters;
the
the
above,
these
Thus,
program
would
supports
of
a
For example, "CHRFLAVOR"
text-oriented
operations.
is
The
which is, of course, hidden from the
CHRFLAVOR
canvas
is
a
vector
and
so
on.
Fig.
of
1.3
original four flavors of JAWS: CHRFLAVOR is explained
a
canvas
supports
of
a
bit-mapped
canvas,
QUIXFLAVOR
vector endpoints, and WINFLAVOR supports
windows with no canvasses (more about this in Chapter 3).
Canvas
A in Figure 1.3 is of type CHRFLAVOR while canvasses B and Z
both
to
routines used to manipulate it may include such
BITFLAVOR
supports
"flavors".
application
things as MOVE_CURSOR, WRITE_CHARACTER,
shows
support
in the flavor which corresponds to the
representation,
application program,
which
as
the
(Fig. 1.3).
a canvas flavor which
in
routines used to manipulate
routines
manipulate a particular canvas,
call
the
differing
are
of type QUIXFLAVOR.
THE WINDOW DATA STRUCTURE
Each window (Fig. 1.4) contains pointers to
views,
to its "screen buffer", which contains
of the canvas' contents in a form
device,
and,
possibly, to
intelligible
the
a
canvas
representation
to
the
a list of child windows.
- 5 -
it
display
A child
Fig. 1.3 -- The application program manipulates the canvasses through
the routines
provided
-6-
by the appropriate
flavor package.
TOPW ND
WINDOW
BOT
NO
L ASTWI
WINDOW
1
NEXTWIND
NEXTWIND
PREVWIND
PREVWIND
SCREEN BUFFER
SCREEN BUFFER
CANVAS
CHILDREN
WINDOW
--
CANVAS
CHILDREN
ND
n
NEXTWIND
PREVWIND
SCREEN BUFFER
-
LI
CANVAS
CHILDREN
\\
CA~NVAS
1
j
U
CANVAS
IL
WINDOW 3
I-
I CANAS
NEXTWIND
PREVWIND
SCREEN BUFFER
CRNVAS
CHILDREN
Fig. 1.4 -- The window hierarchy.
-7-
B
window is no different from its parent in structure (i.e.
have
siblings,
children,
different, however, in that
region
occupied
has
its
view
of
existence
a
canvas).
is
limited
It is
to
the
if a window is a child of some other window,
no screen buffer of its own).
Windows are assembled in an
order
a
by its parent and it shares its eldest parent's
screen buffer (i.e.
it
and
it can
in
which
they
are
hierarchy
which
determines
displayed on the screen.
the
There are
three special pointers into that hierarchy: TOPWIND, BOTWIND, and
LASTWIND.
The windows between TOPWIND and BOTWIND are visible on
the display with TOPWIND appearing to be above all other
windows
and
windows.
allows
BOTWIND
appearing
visible
to be beneath all other visible
This gives a "2-1/2"-D
quality
to
the
display
and
the user to think of overlapping windows just as he would
overlapping papers on his desk.
The windows between BOTWIND and
LASTWIND are said to be "hidden", meaning they are not visible on
the display at all.
In Fig.
the
1.4, then, Window 3 would be "displayed"
contents
of
its
screen
device) first, then Window
displayed
since
buffer (i.e.
buffer transferred to the display
1.
Window
2
is
never
its screen image was displayed
Thus,
have
explicitly
it is a child of Window 1 and shares its screen
Window 1 was displayed).
hidden.
(i.e.
automatically
when
Window n is never displayed since it is
when portions
of
more
than
occupy the same space on the physical display,
- 8 -
one
which
window
window
is
visible
to
the user is determined by its position in the window
hierarchy.
The order of the hierarchy is
order
in
does,
however,
which
displayed
causes
a window
the
JAWS
"Surfacing" a window means that it will always
to
(i.e.
be
causes
(however,
by
provide operations in the "window manager" which
last
it
determined
the application program defines windows.
alter that order.
be
originally
is
displayed
it
its
it
to
TOPWIND);
"burying"
a window
first (it is BOTWIND); "hiding"
become
invisible
to
the
display
screen
buffer is still updated in the event of a
change in its canvas).
In Fig. 1.5, we have surfaced the window
containing the clock display, in Fig.
in Fig.
1.6 we have buried it, and
1.7 we have hidden it.
THE WINDOW UPDATE CYCLE
The changes made to a canvas are not immediately made
on
the
display
explicitly
device; instead, the
indicate
canvas be made visible
that
allows
application
visible
program must
it desires to have the changes to the
before
a
screen
update
occurs.
This
long and complex changes to the canvas seem instantaneous
to the user.
The application program
manager"
that
it
wishes
notifies
JAWS
through
the
"canvas
to have the changes made to a certain
canvas transferred to the screen.
-9-
This causes a series of events
22 Apr 83 16:39:14
Fis. I.5 -- Theclockdisplay is surfaced.
I.nb f
Fig. 1.6 --
The clock display
is buried.
1 :40:35
I
Fi.
I-7 -- The clck display is hidden.
to occur (Fig.
changed
1.8).
canvas
manager
First, the canvas
the
processing
a queue (the "CANVAS QUEUE") for
on
the window manager and invokes that manager.
by
places
In Figure I.8,
B has changed and is therefore on the CANVAS QUEUE.
canvas
For
each canvas on the CANVAS QUEUE, the window manager traverses the
the
entire window hierarchy updating
windows
flavor
which
view
the
changed
screen
canvas
buffers
as
is
of
necessary
in more detail in Chapter 2)
by
discussed
translation routines (these will be
dependent
those
and placing them
on the "REDISPLAY
2
and
3
are placed on the
REDISPLAY QUEUE since they both view canvas
B
(see
QUEUE".
When
In
this
Figure
1.8,
windows
the REDISPLAY QUEUE, the screen
window
display
1.4).
screen buffer update process is completed, the window
For each window that
manager invokes the "screen manager".
on
Fig.
is
manager traverses the entire
therein
the
and
displays each
that
all
changed windows are updated and the depth
so
relationships between
manager to
the
windows
redisplay
window
on
hierarchy
remain
only
the
same.
Were
the updated windows, it
the
screen
may
occur that some obscured window would become the obscurer of
another window which logically
hierarchy)
(i.e.
lies on top of it (a clear mistake).
redisplaying each window in the
"reburying"
the
according
window
changed window.
the
update cycle.
- 13 -
hierarchy
to
the
window
The process of
is
known
as
This screen refresh completes
F i.
1.8
--
The window updat e process.
-14-
THE UTILITY ROUTINES
Just as the application program must perform flavor
manipulations
on
the
canvasses,
so
must
dependent
the
various
managers sometimes perform operations which vary with the type of
An example of this occurs when
canvas a window is viewing.
the
correlate
a point in a window with a
point in the canvas the window views.
Obviously the way in which
window
tries
manager
to
this is done varies with
Because
(e.g.
of
the
type of canvas the
this, there is a need for generic procedures in JAWS
a generic correlation routine).
support
views.
window
such
procedures,
we
Since PASCAL does
not
emulate them by using a dispatch
module as shown in Fig. 1.9 where the flavor utility routines are
analogous to the flavor routines seen in Fig. 1.3.
routines
These utility
are hidden from the application programmer.
ARCHITECTURAL BENEFITS
An important design feature of
mentioned
above
(i.e.
a
multi-processing
that
the
managers
This arrangement allows JAWS to run
environment.
application programs run concurrently and
management
is
the canvas, window, and screen managers)
communicate through queues.
in
JAWS
Not
use
only
can
several
the
same
window
system, but also the various managers of JAWS can run
concurrently so that events not related to one another can
independently.
all
For
occur
instance, in a single process environment,
canvasses have to be translated into the appropriate
- 15 -
screen
-~~~~~~~~~~~~~~~~l
SCREEN MNAGER
Fig. 1.9 -- The DISPATCHmodule emulat es
for JHWSmanasers.
-16-
eneric procedures
buffers before the screen buffers can be
is
unnecessary since the display of a given screen buffer
logically
depends in no way upon the translation of a canvas
screen
This
redisplayed.
buffer.
Also
another
into
queue architecture makes it extremely
the
to add new managers to JAWS.
easy
A second important benefit of JAWS' design is that application
programs written using JAWS are somewhat device-independent.
this
I
mean that if JAWS were to be moved to another machine or
made to support a different device, application programs
using
they
which
managers
were
written
interface
that provided by the three
(i.e.
and the flavor routines) would still be the same.
Another benefit is
support
written
would still run (provided the language in which they
JAWS
are written is supported on the new machine) since the
to
By
different
that
canvas
JAWS
can
be
readily
data representations.
expanded
to
To do so, one
simply writes a flavor package to support the new representation.
There is no theoretical limit to the number of flavors which
be
supported
imposed
by
by
the
can
JAWS; there may, however, be a practical limit
system
supporting
the
implementation
(for
instance, some linkers may have a limit to the number of separate
modules a program can contain).
are
detailed
Two examples of flavor additions
in subsequent chapters.
- 17 -
SOME INADEQUACIES
The design just described has several problems whose solutions
are the major focus of this thesis.
The most
visibly
apparent
problem (to one who is running a program using JAWS) concerns the
reburying of changed windows.
flicker
slightly
as
the
various
source of this problem is
screen
manager
Each reburial causes the screen to
that
redisplays
windows are displayed.
to
accomplish
every
visible
hierarchy in its entirety each time a screen
(i.e.
reburial,
The
JAWS'
window in the window
buffer
is
changed
each time something appears in the redisplay queue).
resultant flickering is intolerable in
interactive
The
applications
which require several screen updates per second.
As is detailed
below, this is neither
and
necessary
nor
efficient
has
been
greatly improved upon.
A second major problem with the above design is
of
child
windows.
The
original
design
of
its
JAWS
handling
makes
following distinction between child windows and windows
with
the
no
parents ("top-level" windows): only top-level windows have screen
buffers
(see
implications.
overlapping,
Windows
1 and 2 in Fig.
For one, child
for
if
they
image would be destroyed by
regenerated
windows
were
the
from the canvas.
are
This has several
restricted
to
not
to overlap, one child's screen
other
and
would
have
to
be
Another implication is that if a
top-level window has children and is
screen
1.4).
subsequently
updated,
the
image of the children would be overwritten and would have
- 18 -
A
to be regenerated from the canvas.
windows
child
windows
by
have
the
Consequently,
to
window
these
two
be
and
by
screen
the
manager.
be
treated
a more general fashion.
the
Another small, but significant, design oversight is
of
that
are filled with special case
managers
code which could be eliminated were child windows to
in
is
drawback
differently from top-level
treated
manager
third
lack
a facility for defining windows which have no screen buffers.
There are four possible combinations of possessing screen buffers
buffer/no
canvas),
but
and no buffer/no canvas).
(buffer/canvas
these
and
ignores the other two (no buffer/canvas
The no buffer/canvas option is similar
windows
of
to the default configuration
(Weinreb and Moon).
of
two
and canvasses; JAWS exploits
on
the
Lisp
Machine
Its main advantage is that it saves storage
Of course, such a
(this is especially true on a raster display).
Since
concept is applicable to only a small set of applications.
the screen manager does need to refresh the
screen,
the
loss
in
canvas representation must be fairly compact.
screen
Also, in order to
image of the canvas must be easily generated.
make the storage savings worth
the
update
time,
the
The details of the
implementation of this feature and of the development of a canvas
flavor
which
utilizes it are given in Chapter 3.
Another deficiency affected JAWS' usefulness
programs.
This
is
for
interactive
not the result of a design oversight; it is
- 19 -
simply
a
lack
programs,
we
of
function.
Often
when
using
interactive
select from a small set of commands and data.
In
such a case, it is both feasible and more desirable to select the
command or datum from a menu instead of typing
keyboard.
need
only
selection.
the
from
the
know
how
to
more
move
desirable
since
the
the pointer and indicate a
In some cases, to save screen space, we may wish for
menu
to
display
only some of the available options and to
have the ability to scroll to the other ones.
to
in
When a pointing device (such as a puck or a mouse) is
available, this feature becomes even
user
it
have
Also, we may wish
a facility for indicating some modal difference between
various options
arguments).
on
To
the
and
details of
insight
a
pop-up
multiple-fonts,
its
into
(such
as
between
commands
and
avoid having each application program implement
its own menu facility,
scrolling
menu
implementation
menu
has
flavor,
been
(given
which
in
added
supports
to JAWS.
Chapter
2)
The
provide
writing flavors for JAWS.
THESIS ORGANIZATION
The remainder of this thesis
detail
on
the
issues
is
devoted
mentioned above.
to
providing
Chapter 1 details the
various screen management algorithms used to solve
problem;
from
the
Chapter
more
the
reburial
original
2 describes the implementation of pop-up menus
design
considerations
- 20 -
to
the
final
data
structures
and
algorithms
used;
Chapter
3 describes how JAWS
might be modified to support canvasses whose
generated
dynamically
instead
of
being
discusses the advantages and disadvantages
with
the
two
implementations
screen
buffered;
we
have
to support POLITE.
- 21 -
JAWS
are
Chapter
4
experienced
of child windows (i.e.
without screen buffers); Chapter 5 discusses how
used
images
with and
might
be
CHAPTER
1
SCREEN MANAGEMENT TECHNIQUES
There
two
are
screen management.
the
major
involved in achieving efficient
steps
The first step involves limiting the area of
management to only that area which has been changed.
screen
This may seem to be an obvious procedure, but it is one which the
original implementation of JAWS ignored (recall that the reburial
process was accomplished
by
determine the bottom (i.e.
the
to
closest
to
window
be
the entire hierarchy is not
of
so
necessary.
For instance, if a window is being surfaced, then it
the
bottom
window
to
be
the area to be
and
redisplayed
the area filled by the window.
is
redisplayed
redisplay
BOTWIND)
redisplayed
is
that
in
window
A related but ancillary step is to
in its ENTIRETY).
hierarchy
EACH
redisplaying
COMPUTATION OF THE CHANGED AREA
The actual calculation of the extent of the
done by the redisplay routine.
for
this
the
window's
summing
the
offsets
absolute
of
screen
is
its
parents
included
by
in
adding the window's absolute
the changed area within the window.
changed
area
the
first
sum).
of
offset
offset
to
the
parents
origin
Next,
the
the
changed
the offset of
The width and height of the
were previously determined by the
- 22 -
their
from
this
by
screen
from
window
redisplay routine computes the absolute
area
on
offset
(ultimately, the offset of a top-level
the
is
The routine (Fig. 1.1), expressed
thesis in terms of Pascal plus set operations,
computes
of
area
changed
caller
of
the
PROCEDURE
rcdtsptp (ultndou, startx, starts', wd
wlit , h, tg
ht)
[xoff'set <- wi,nuow->.offsetx;
poffse4 <- witondo->.offsetp;
par.3at <- window-\x.par
s <V U
E
{ at
s DO
ancestor
wtandows of wtndiow >
[xof.fst <- xoffset + w->.of'fsetx
yoffset
<- poffset+ W->.offsety]
xoffs-ct<- xofffset+ stctx;
ewtcuc(relisptypactgut,
scr eca_mnager
poffsct
- yoffsct + sart.p;
utrtow, xoffset,
offsetw, wttt
Fig. 1.1 -- The redisplay alorithrn.
-23-
eght)
window
redisplay routine; therefore, if the entire
redisplayed,
the
were
to
be
redisplay routine would be called with offsets
of zero (indicating to redisplay from the upper-left-hand
corner
of the window) and width and height equal to the width and height
of the window.
After
it
routine
redisplay
the
computes
creates
a
the
containing
the
element
queue
above
information (the window to be displayed
area)
and
and
it
is
to
the
the
place
both the screen's coordinate system and the window's
the
hierarchy.
The
in
respect
to
this
position in
screen manager faces the task of computing
exactly what is visible to the user.
doing
window
the screen in its proper position with
on
changed
It then invokes
places it on the redisplay queue.
the screen manager, whose job
question
coordinates,
changed
absolute
computation;
all
There are several ways
have
strengths
different
of
and
weaknesses.
SCREEN MANAGEMENT ALGORITHMS
JAWS' screen manager was
algorithms
detail
and
implemented
for the overlap computation.
compare those algorithms.
- 24 -
using
three
different
The following sections
THE DO NOTHING ALGORITHM
the
with the bottom
Starting
that portion of the window which was influenced is
on
displayed
DNA continues until it reaches TOPWIND, at
display device.
the
if
If it is, only
"influenced" by the changed coordinates.
is
here
1.2) examines each window to see
window (BOTWIND), DNA (Fig.
it
(DNA).
algorithm
Nothing"
"Do
term
I
The original enhancement to JAWS employed what
which point it is done.
of
The best feature
is
its
algorithm is extremely inefficient.
BOTWIND,
it
simplicity;
the
is
code
Unfortunately,
this
To begin, by starting
with
quickly.
executes
and
simple
extremely
DNA
the fact that only those windows which lie
ignores
above the window on the redisplay queue need to be placed on
screen to insure its proper reburial.
the
Secondly, by ignoring the
relationships the windows in the hierarchy have
to
one
another
(i.e. that some windows overlap), DNA often displays pixels which
are
going
only
to be overwritten by some subsequent writing in
The first inefficiency compounds the second.
the same reburial.
DNA's simplicity would be worth the incurred inefficiencies if
performance.
manager's
any
large
area
of
not
did
inefficiencies
those
the
noticeably
affect
the
screen
Unfortunately, they do; the reburial of
(large
screen
means
approximately
one-thirtieth of the screen) results in a very noticeable flicker
of
the
image.
If any sort of interaction is occurring in that
area (for instance, scrolling), the resultant flickering is very
- 25 -
PROCEDUREscreen.r .nrer
[s <-
()
wtndows betweert BOTWIND adnA TOPIIND
wintaow
<- dc.uett
r( td.sptc
1,ptue)
V w E s
[IF
Fig.
DO
(w-tndow
n.:ftu..ences
w)
[(tdispt6cVtnfttencc.
1.2 --
THEN
portionr- of w)]]]
The "Do Nothing" algorithm
-26-
(DNR).
The reason for this is that in
distracting and unappealing.
interactive
intensely
the
application,
obscured
window
displayed almost as frequently as the windows which are
to
obscuring
be
an
is
supposed
it.
DOING NOTHING TO A SHADOW BUFFER
The second algorithm
like
is
DNA,
instead
only
buffer" which is subsequently copied onto the screen,
"shadow
eliminating the flickering we experienced with DNA.
thereby
call this algorithm DNASB (for DNA in a Shadow Buffer).
advantage DNASB has over DNA
windows
window
from
the
changed
is
it
that
displays
those
in the hierarchy).
price we are paying to achieve that performance.
have
an
additional
(compare to DNA's
management.
capable
buffer
simplicity)
to
and
seem
what
First, since we
we need more code
manage,
more
consider
time
to
perform
the
Second, we must consider that the shadow buffer must
of
containing
an
entire screen's worth of data
(since that is the largest part of a window can be
The
would
This may be true as far as the
aesthetics of JAWS is concerned, but we must also
once).
A second
forward (DNA displayed each
window
that it is much better than DNA.
be
We
only
Since DNASB does not cause any screen flicker, it
now
of
the images directly onto the screen, it writes them into
writing
a
tried
implication
of
this
is
that
we
displayed
must
have
at
an
additional amount of storage equal to the storage consumed by the
- 27 -
screen buffer (in the PERQ, that comes to 96K
for this buffer.
this
much
bytes)
set
aside
If the underlying computer system does not have
memory, cases may arise in which the algorithm simply
does not have room enough to run; if the underlying system has
virtual
memory
system,
this
storage
consumption may lead to
excessive swapping for highly interactive programs.
note
that
DNASB
Finally, we
is inherently less efficient than DNA since it
has to do almost twice as much work just to display the
the screen.
and
the
displaying
only
image
display.
Of
course,
in
DNASB's
the
shadow
tactic
of
those windows lying above the changed window in
the hierarchy does give it some redeeming value,
be
on
almost as much work as DNA does to move the shadow
buffer onto
easily
data
This inefficiency occurs since DNASB has to do work
equivalent to that of DNA to generate the
buffer
a
modified
to
do
the
same
but
DNA
could
without taking on any of
DNASB's less desirable features.
THE FRAGMENTATION ALGORITHM
The third algorithm we tried is
considered.
For
reasons
the
best
of
the
form
is
given
in
we
which should become clear shortly, we
term it the "multiple pass fragmentation" algorithm
basic
three
Figure
1.3.
The
(MPF).
idea behind the
algorithm is to exploit the notion of "subtracting"
an
window from an obscuring window and being left with the
- 28 -
Its
obscured
visible
PROCEDURELpf (wtondow)
windo w) THEN
[ IF (c cce window tniftuencs
Is <:
V
-wirndow
w E s
[V
} +
+ { wiLvtndo's ctitd&rer
[IF (c}geiwitr4ow
v
E
If
s
tnftunaces
witrnloi's
ktgheZr
DO
- { frmgnents
s <- s - {vU
fron
+ f ]]
v subtrocted
from
red.tsp_1st <- recdtsp_1st + s]
IF b.ry-tg
OR sur.f'acit
THEN
[ (call tLpf on, wlDindo s cldrcn)
IF burpitng THEN
[(c la mapf on witnAo w's
PROCEDUREscr een mowr
[chge wndow - dx
red&is7
st
tig er
s bli3 gs) ]]
()
toyGIeue)
tc rccSts
- {}
mf ( c k~ecd_wtndow)
V i
E rcttsp_ls
[ (d.'tsptay
F i 9.
t
DO
w on t}w. screen)
1.3 --
s-tbl1,rs } DO
w) THEN
]]
The Multiple
Pass Fragmrnentation
(MPF).
algorithm
-29-
w }
fragments of the obscured window.
This notion is key to the rest
Now, to determine what is to be displayed when
of the algorithm.
a window changes, we simply subtract it from the window above it,
subtract each of the resultant fragments from the next window up,
and
so
Unfortunately, this is not always adequate.
on.
For
instance, if a window is being buried, it is not enough to figure
what part of it is showing, but we must also figure what parts of
showing
the windows above it are
simply
to
properly
bury
it.
This
that in the case of a window being buried, we must
means
invoke the algorithm recursively on the window's children and
A similar situation
the windows lying above it in the hierarchy.
arises
in
the
however, the
case
a window being surfaced; in this case,
of
algorithm
on
need
be
invoked
recursively
for
the
does
not
changed window's children only.
How does MPF compare to DNA and DNASB?
First,
it
allow the screen to flicker, so it is immediately a step ahead of
DNA.
Second,
its storage consumption is limited to descriptors
for window fragments instead of large display buffers as
in
DNASB.
But
performance
performance
characteristic:
degrades in proportion to the difficulty of the
problem to be solved.
The implication of this is that the
who desires a simple, non-overlapping display does not incur
same
overhead
saw
the major distinction between MPF and the other
two algorithms is MPF's interesting
its
we
as
user
the
the user who wishes to have a complex display
with lots of overlapping windows.
- 30 -
By contrasting this
property
with
(where overlapping windows are not even supported very
DNA
and DNASB (where the user must always have the storage and
well)
time overhead whether he uses overlapping windows or not), we see
that MPF affords the user a great deal of
MPF
best,
windows.
performs
well
as
does
DNA
At
its
on non-overlapping
On average, it outperforms DNASB and sometimes even DNA
overlapping
on
as
flexibility.
windows (see Appendix A for details).
Of course, there are two sides to every story, and MPF's story
is no exception.
To begin, there is a lot more code for MPF than
there is for either of
to
amounts
the
others.
The
only about ten per cent of the entire window system,
so if one can afford JAWS without MPF then surely he
the execution time of the MPF algorithm.
on
large problems (compare with DNASB's
As
Appendix A
(this
afford
Simply put, MPF is slow
constant
performance).
indicates, MPF begins to become slower than DNASB
the user tries to bury a window beneath
when
can
The second problem is more serious and concerns
with MPF.
JAWs
however,
difference,
about
six
others
depends on how the six are arranged on the screen;
really
complex patterns tend to take longer than less complex ones (Fig.
1.4)).
If we plot the performances of MPF and
complexity,
we
will
see
DNASB than it is to run MPF.
be
able
a
DNASB
versus
problem
point at which it is better to run
The optimal algorithm, then, would
to analyze a window configuration according to some
- 31 -
-
-
-
.
.
I
I
(a)
(b)
Fi 9. 1.4 -- Conf i3urat ion (a) is relatively
(b) is relativel.y simple.
-32-
complex h
hile
-
-
complexity criteria and then run either MPF or DNASB depending on
where the configuration's
course,
then
we
complexity
the
graph.
Of
the problem of scrounging up
regain
would
on
fell
enough
memory to run DNASB in its worst case unless we took that
factor
into
account
deciding which algorithm to run.
while
noticed
The perspicacious reader will no doubt have
the
that
of
screen management algorithms we implemented, none was
three
the technique
complete
as
known
bit-maps
viewing the
solution
other).
for
is
that
"double
the
The
buffering"
display
reason
we
and
did
(i.e.
drawing
not
having
two
on one while
implement
this
one of our principal objectives was to reduce
storage consumption; double buffering guarantees that we will use
twice
the
storage
normally consumed by the display.
- 33 -
CHAPTER
2
POP-UP MENUS
chapter is concerned with the implementation of a canvas
This
flavor which
Because
below.
of
pop-up
menu
function,
we
the
supports
its
abstraction
described
have chosen to name the
This chapter is divided into two major parts:
flavor POPFLAVOR.
the first part refines the pop-up menu abstraction and the second
part
details the implementation of POPFLAVOR.
WHAT SHOULD A POP-UP MENU DO?
A typical pop-up menu allows the user to select
a
moving
pointing
(such
device
as
an
entry
a mouse or a puck) into a
position which is enclosed by the area of the desired entry.
menu indicates to the user that it
a
recognizes
selection
entry in some way (Fig.
highlighting the selected
the
pop-up
menu
in
Figure
2.1
has
a
by
scrolling
been partially
scrolled by using the scroll bar on its right margin.
then
The
To aid
2.1).
the user in browsing, the pop-up menu also provides
feature;
by
The
user
makes some finalizing action (such as pressing a button) to
let the menu
selection
entry
know
that
the
selection
is
final.
selected
we
is acted upon by the application program.
described
How
find ourselves faced with some pressing issues.
does the menu get
selection
the
is finalized, the menu is hidden from the user and the
When we attempt to implement such an interaction as
above,
After
its
contents?
Who
is
in
control
action: the application or the window system?
of
the
If the
window system is in control, how much information does it need to
- 34 -
21 Apr 83 12:07:56
This
is a character
flavor window.
¾nd
Opttons:
MOVEL
Lit
MOVE
RUN
a
W.=l
RESHAPE
MRKE CHILD
" I
.....
~..
...·............
......... ;
Fig. 2.1 --
The pop-up menu indicates a selection
the se ected entry.
by highlighting
know about the contents of the
selection
activities?
the
menu
in
order
to
support
the
How is the selected entry related to the
application
(if
window
system
selection)?
What happens if there are more entries than will fit
into a reasonably large screen area?
is
in
control
of
What happens to the screen
area that is temporarily obscured by the pop-up menu?
the
user
the
How
does
indicate that he wishes to make no selection, but just
wants the menu to go away?
implementation
The
following
description
of
the
of pop-up menus addresses these and several other
issues.
IMPLEMENTATION DESIGN ISSUES
The first issue we must resolve is who is to be in control
the
pop-up
system?
menu
interaction:
the
application
or
of
the window
Clearly, there are advantages and disadvantages to each.
One may wish to have the application implement the pop-up menu if
one desires a considerable degree of control
provided
by
the
menu;
if
over
the
features
the window system provided a pop-up
menu, there is a danger that
the
have
fine details of its behavior.
no
choice
about
the
application
programmer
would
The
disadvantage to having no window system provided facility is that
each application would then have to create its own.
be
inefficient
some
would
since functionally equivalent code would be have
to be written and debugged for
were
This
each
application
(unless
there
compatibility among applications that allowed modules
- 36 -
to be shared, but then we open up a can of file system management
that
It seems, then,
worms).
a
reasonable
would be to have the window system provide a pop-up menu
problem
provide
flexibility
the
menu facility, it is
menu
pop-up
more
this
Although
facility with application-defined options.
not
the
to
approach
does
of an application specific pop-up
flexible
than
one
having
standard
provided by the window system.
Once we have chosen to have
the
window
system
the
provide
pop-up menu facility, we must establish a method of communication
between the application and the window system.
the
specify
application
the
of a menu to the window
contents
Since the basic components of
system?
First, how should
menus
entries,
are
it
seems logical that the application should specify a menu on a per
basis.
entry
So,
for
each entry the application wants in the
menu, it must specify the contents of that entry and
options
window).
(e.g.
a
list
of
what font to use when writing that entry into the
The window system would use this information to
build
an internal representation of the application's menu and give the
application
a
name
it can use to refer to that representation.
To use the menu to get input from the user, then, the application
would simply invoke the
window
system's
routine
for
handling
input from pop-up menus with the desired menu's name as argument.
The
invocation
of the pop-up menu input routine brings us to
the next major issue: how is the input
- 37 -
received
by
the
window
system specified to the application?
of communicating the information.
There are two obvious ways
One is to return the number of
the entry selected to the application.
The disadvantage of this
is it requires the application to maintain his own data structure
of
the
contents
consistent
with
(although
this
of
the
the
data
menu
and to keep that data structure
maintained
by
window
system
is easy to do when pop-up menu is first defined,
it may be troublesome if we allow the user
interactively).
the
This
method's
advantage
require the application to parse the input.
to
change
is
the
menu
that it does not
Parsing may not
be
much of a problem when the menu's entries are restricted to those
defined
by
the
application,
but what happens when we place no
restrictions on the user's ability to
change the menu to include
commands mixed with data instead of using several levels of menus
to specify data?
user
is
How can the application
understand
string
contents
of
the
selected entry.
to
method's.
in
entry
Since either method is better under different
circumstances, the best solution is to allow the
specify
return
This method has
advantages and disadvantages which are the opposite of the
number
the
trying to do without performing some parsing?
The other way to communicate the selected entry is
the
what
application
what form he wants the input to arrive.
- 38 -
to
SPECIFYING THE IMPLEMENTATION
The following discussion on the implementation of POPFLAVOR is
a general one whose ideas apply equally well to all
packages.
JAWS
flavor
POPFLAVOR is used here only as a medium for expressing
those ideas.
Now that we know the inputs and outputs
of
the
pop-up
menu
facility, we must decide how to implement something which adheres
to that specification.
some
Since we are implementing this as part of
window system, we should first decide how this feature fits
into the rest of that system.
JAWS;
In our case, the window system is
since, as was indicated in the introduction, abstract data
types in JAWS are typically implemented by flavor
should
implement
pop-up
menus
as
a
flavor
packages,
we
(hence its name,
POPFLAVOR).
As a flavor package, POPFLAVOR must do two things: 1) it
provide
an interface
POPFLAVOR
canvasses
to the application
and
to allow
must
it to manipulate
2) it must provide routines to support
applicable generic routines for the window system.
Because
the
functions
narrow,
the
provided
by
a
pop-up
menu
application interface can be rather small.
required
by
are
so
The major
functions
the application are the ability to insert an entry,
the ability to delete an entry, and the ability to get input from
the user through the pop-up menu (the application programmer
may
also desire functions which allow him to modify existing entries,
- 39 -
but
for
the
purposes of our discussion, these are ancillary to
those functions listed above).
Supporting the functions required by the rest of JAWS (through
the DISPATCH module
slightly
more
as
mentioned
demanding
in
matter.
In
the
introduction)
is
a
addition to the somewhat
trivial tasks of creating and destroying POPFLAVOR canvasses, the
POP_UTILS module must also support the correlation of
points
on
the
APA screen with entries in the canvas and the translation of
the
canvas representation into a bit-map.
THE IMPLEMENTATION OF A POP-UP MENU CANVAS
The implementation detailed below was developed with the above
considerations in mind.
the
data
representation
The description given
used
first
specifies
and then proceeds to specify the
algorithms used to perform the correlation and translation (these
are the two most interesting problems associated with the
pop-up
menu canvas).
Since the application may make and delete entries at arbitrary
points in the menu and the menu may grow to
the
an
arbitrary
size,
data structure we choose must support these concepts easily.
For this reason, the top-level
structure
linked-list of entries (Fig. 2.2).
representation
is
the
storage
of
the
canvas
is
a
The only disadvantage to this
consumed by the pointers in the
linked-list (on the PERQ, pointers consume two sixteen-bit words
- 40 -
ENTRY
ENTRY n n
!
Fig.
2.2 --
The top-level
a linked-list
structure of the pop-up menu canvas
of entries.
-41-
is
each).
our
There are two reasons why this is not a major
case:
1)
typical
pop-up
issue
in
menus are on the order of ten to
twenty entries (remember that they are supposed to
make
a
more
interface, so they will probably be kept brief to avoid
friendly
clumsiness) and 2) the PERQ has
memory,
one
bytes
million
of
primary
a few words wasted are not that important to us when
so
balanced against the increase in efficiency we achieve.
however,
forced
presented
with
to
either
multiple-font
a
assume
canvas
a
more
more
conservative attitude when
demanding
presented
in
We are,
task
Chapter
5)
(such
as
or
smaller
a
the
machine.
Next, we must specify what constitutes
(Fig.
SPACING).
The
An
entry
per
it
can
menu,
there
can
although
be
only
there
(FONT
and
can
be
several
one font per entry); the
SPACING field determines how many bits of white
is
assume
FONT field determines what font the TITLE string
is to be written in (note that
space
entry.
2.3) consists of three major parts: the string form of the
entry (TITLE) and the two attributes
fonts
an
(or
background)
to be left between consecutive entries or an entry and
the window border.
Entries
must
also
implementing code.
contain
information
to
assist
the
An example of such information is the forward
pointer for the linked-list.
There are several other such fields
in the entry structure which we present along with the algorithms
that
utilize
them.
- 42 -
Fig. 2.3 --
n ENTRY is composed of three fields: the TITLE field,
the FONT field, and the SPRCING field.
-43-
We now consider the correlation
Since
the
translation
and
algorithm
translation
depends
algorithm, we present the latter first.
needed
to
perform
coordinates
to
(BIT2ENTRY).
bit
easy
to
correlation
Once
write
conversions
(ENTRY2BIT)
entry
from
and
the correlation routine (Fig.
vice
then,
becomes
how
to
write
isn't
versa
these
two
The simplistic answer is to start at the top of the
of interest.
first
entry
quite so simple.
find
process
to
be
too
slow
However,
Were we to actually implement the
primitives this way, we would
would
and
This basic technique is the underlying
principle for both ENTRY2BIT and BIT2ENTRY (Fig. 2.5).
life
entry
2.4).
canvas and count the bits consumed between the
the
correlation
these primitives are established, it becomes
The real question,
primitives.
the
The primitive functions
are
coordinates
on
algorithms.
that
the
canvas
selection
keep up with the user and that
smooth scrolling would be out of the question.
What can we do to
improve the performance of this basic algorithm?
The answer lies
in remembering the answers to our previous queries (somewhat like
dynamic programming).
To implement this solution, we need to add
a field (the BITS_CONSUMED field) to our
tells
entry
structure
which
Now,
us how many bits from the top of the canvas each entry is.
ENTRY2BIT
becomes
BITS_CONSUMED field (Fig.
trivial;
2.6).
we
simply
look
examining
the
BIT2ENTRY still requires us to
start at the top of the canvas and search down, but
merely
at
now
we
the BITS_CONSUMED field and totaling our
- 44 -
are
tn· ger
wtnx, wtriy)
fuSnctio pocorretole(wnuow,
(carry - titZentry(wiAdowA.ccwcas,
wtniow^.i,vewposy + wir - windUow.topmarg )
RETURN
( cany ) ]
Fig. 2.4 --
The correlation
of BITZENTRY.
routine written assuming
-45-
the existence
BIT2ENTRY(cvuas, b-ttcoor)
functior
ldt eatries
[E - {
E DO
V e
i
; tot _ist
cuas
<- 0
's font) +
<- tot ctist + (the height of
for
j
(the tottl sacig
loop)]
IF tot_cist > bttcoor THEN (c.e
[tot_ itst
RETURN(e)]
funcit-orENTRY2BIT(covas, emtrycoor)
[E <- { a.o. eatrtes up to erntry
tot clist
V
c-
E
- 0
entrycoor
DO
[totdisst <- totdist+ (the height of e's font) +
(the total
RETURN (totst
Fig.
tabetted
2.5 --
spactng for e]
)]
The primitive correlation routines: BITZENTRY and
ENTRYZBIT.
-46-
functton BITZENTRY(cunvoas bttcoor)
[E <- { ad.t etrtes tn.canvas
; tot_dst
V e
<- 0
E DO
[tot ditst <- tot d-lst + e.btts consumed.
IF ot_&dtst > bttcoor THEN (teuve toop)]
RETURN(e)]
functtor ENTRY2BIT(canuas, rntrcoor)
[e <-
(he
rentrpcorrespoaitna
to ertrycoor)
RETURN( . btts_corsuad)
Fig. 2.6 --
BIT2ENTRY and ENTRY2BIT modified to use the
BITS_CONSUMED field of each entry.
-47-
findings (Fig.
2.6) instead of calculating the bits used
entry
finding
through
by
an
totalling its font height and total
and
spacing.
We
must
remember
BITSCONSUMED
to
take
is
field
care
to
be
sure
accurate.
always
menu
the
menu
(these
bit coordinates are absolute, not relative, values).
has the disadvantage of making insertion
entries
expensive;
more
will
operations
probably
we
and
done
of
that
though,
infrequently.
rather
ENTRY2BIT
BITSCONSUMED
menu
these
The
accurate.
field
If
described
above;
calculate
the
it
accurate.
it
correct
for the
concerned
has
entry
then the algorithms would proceed as
is,
if
field
is
not,
then
insert
value,
the
it
algorithms
the
unpredictably slow at times.
disadvantage
of
would
in the BITSCONSUMED
field, and use the COMPUTED field to mark it as
method
is
and BIT2ENTRY algorithms would be modified, then,
to first see if the BITS_CONSUMED
This
This method
deletion
recognize,
be
indicates whether or not the
is
operations
is to maintain another field (called COMPUTED) which
alternative
The
menu
coordinates of subsequent entries because those
bit
the
the
and whenever a new entry is inserted in the
creation
middle of the menu or deleted from
affect
two
One method would be
field for each entry in
to calculate the BITSCONSUMED
the
are
There
alternative methods for achieving this goal.
upon
that
being
making
accurate.
operations
Which method is preferable depends
- 48 -
on where the application programmer prefers to incur the overhead
associated
with this technique.
Once we have the correlation primitives, we are ready to write
the other major routine: the translator (Fig. 2.7).
the
mission
of
the
translation
routine is to take the canvas
representation of a pop-up menu and convert it
The
Recall that
into
a
bit-map.
first step we must take toward performing the translation is
to decide what portion of the canvas to translate.
information
from
one
of two sources:
determine
what
to
translate
by
translate
looking
at
coordinates written by the mutating routines (i.e.
which
change entries).
the translation's target
buffer)
is
affected
of
the
or
we
the changed
the
routines
Next, we must determine what portion of
buffer
(this
is
typically
by the change in the canvas.
INFLUENCED in Figure 2.7 performs this task.
bounds
this
Either the caller of the
routine tells us what portion of the canvas to
can
We get
a
screen
The call to
Once we
know
the
translation (in bits), we simply write the TITLE
field of each entry within those bounds into
the
target
buffer
using the font indicated by the entry's FONT field and leaving as
many
bits
of
space as are requested by the SPACING field.
HANDLING INPUT
The actual handling of user input is made trivial by the power
of the primitives we have defined.
- 49 -
The input routine (called
procecurxe POPTRRNS(wtlndow, canvas, chg_coords)
[IF chged
coorcLs = {} THEN
[chge&-coords
<-
changed
coords
o
canvas
chFged coords <- tnfltlencei&( wtnlow, chgectcoords)
IF checl_coords
[
c
E chged
1
{} THEN
coords
DO
[( write fTe canvuas etry corresponding to c inLwindow at
ENTRYZBIT
(canvas, c) with proper font ad spacing ) ] ] ]
FiB. 2.7 -- The translation
routine
ENTRY2BITprimitive.
-50-
is easy write using the
f
is simply a loop (Fig.
POPPICKNCHOOSE)
coordinates
2.8) which fetches the
of the user's pointing device, correlates that point
with a point in the canvas, checks for any
does
appropriate
the
the
(highlight
thing
change
the
onto
the
window
the
go
to
translator
invoking
and
the
the pop-up window onto the top of all other
popping
making
windows on the screen is simply a SURFACE operation;
window
system
the screen; scrolling is achieved by
changing the window's view on the pop-up menu
translator;
scroll,
entry,
achieved by changing the highlight
is
Highlighting
attribute of the selected entry and invoking
transfer
an
upon entry and hiding it upon exit.
window
pop-up
These functions are easily implemented using
primitives.
and
presses,
This routine is also given responsibility for
terminate, etc.).
placing
button
the
away when the user is done is simply a HIDE operation
(recall that JAWS supports overlapping windows, so refreshing the
area which is temporarily obscured by the pop-up window
done
by the window system).
automatically
One
is
issue
remaining
POP_PICK N CHOOSE.
is
how
to
the
terminate
loop
in
We chose to terminate when the user presses a
button
while
pointing
outside
the
pop-up menu's window (Fig.
2.8).
There are, however, alternatives to
this
strategy.
If
are several buttons available to the user, the application
there
programmer could designate one of them as the terminating button.
We could extend this notion to include all keys on
(we
should
be
careful
here
the
keyboard
to remember that we use pointing
- 51 -
funcZtiom POP PICK N CHOOSE(wirtnow)
EsuracewTndowTREPEAT
(I <- ( pointer positionL tL bits )
C <-
BITZENTRY(wtndow
IF C E { at
[igktgit
^.
crwcas
I)
erntries iat Wndow^.Ccanvos
(C) ]
ELSE
[IF ( I s Vtascrott regito
[(changc vtew of wtndw
UNTIL ( button is pressec )
o
THEN
of winadow ) THEN
cao.s
and cl
POPTRANS
hiZe (w-indow)
RETURN(c)]
Fig. 2.8 -- The input handling routine for pop-up menus.
-52-
)]]]
devices to get away from using the keyboard so
we
much).
could designate an area within the pop-up menu's window to be
the termination area.
All of these alternatives have one
in common: they free one expressive resource (e.g.
or a button) at the expense of tying up another.
is
Finally,
no
one
paradigm
certain that the
that
window
a window area
Although there
is correct for all situations, it is
system
should
allow
the
application
programmer
as
features.
Such a perspective is consistent with our
provide
the
much
freedom
application
thing
as
possible
programmer
with
in
specifying
such
desire
to
the convenience of a
pop-up menu facility that is built into the window
system
while
not constricting his ability to specify what features that pop-up
menu
facility
applicable
not
possesses.
Once
again,
these
principles
are
just to POPFLAVOR, but to all flavors we design.
- 53 -
CHAPTER
3
DYNAMIC REDISPLAY
The
original
implementation
of
JAWS was flexible enough to
support windows whose canvasses were
(Fig.
3.1).
This
arrangement
extra storage that would have
canvas
their
own
screen
had the advantage of saving the
been
taken
up
by
a
bit-mapped
of the same size as the window's screen buffer (note that
this notion is applicable only to windows which
canvasses
since
screen
buffers
disadvantages, of course, are that
become
buffers
immediately
apparent
are
any
in
the
view
bit-mapped
bit-mapped).
changes
screen
to
The
the
buffer
canvas
and
canvasses must be the same size as their viewing window's
such
buffer.
This concept has a limited scope of application, but we
did find it to be
images,
screen
useful
for
windows
which
contained
static
such as a window containing a background pattern for the
(Fig. 3.2).
An analogous concept which was not exploited in
implementation
of
advantage
used
for
disadvantage
original
Such an arrangement is similar to the
default windows on the LISP
principal
the
JAWS is that of windows which view canvasses,
but have no screen buffer.
been
screen
the
is
machine
(Weinreb
and
Moon).
Its
the saving of the space that would have
screen
buffer's
bit-map;
its
principal
is that sometimes it may be difficult to regenerate
a window's screen image from its canvas quickly enough to support
the application.
This concept, too,
has
a
limited
range
of
application and is useful mainly for windows which view patterned
canvasses
since
the
regularity
of patterns makes it
- 54 -
easy
to
WINDOW x
NEXTWIND
PREVWIND
,:~~~~~~~~rpppm
P~~~~~~~~~~~~~~~~i
iip~
---
CANVAS
I
I-
I
CHILDREN
I
F is. 3. 1 -- A window's screen buJffer may also serve as i ts canvas.
-55-
Fig. 3.2 -- The background pattern
is implemented ysing a window
whose canvas is its screen buffer. This implemenation
uses half the srage
that the same wind w would use
were i implemented normally (i.e.
with separate c~anvas
and screen uffr).
the
The following section describes
generate them dynamically.
use
of this concept for a more space-efficient implementation of
the
background pattern of the screen mentioned above.
Since flavor construction is discussed in Chapter 2, I
assume
here that the reader is familiar with the basic concepts involved
flavor construction and, therefore, concentrate here on those
in
features of this flavor
for
primarily
the
(termed
it
since
BACKFLAVOR
is
used
generation of background patterns) which are
(such
flavors
different from the analogous features of "normal"
as CHRFLAVOR).
BACKFLAVOR's major different feature is that it
translation
of
data
from
the
from
differs
This
translation
into
makes
feature
the
the
into
normal
window's
representation into the
canvas
bit-mapped representation directly
the
display's
which
flavors
screen
the
performs
buffer.
buffer.
perform
Because
the
this
the translation visibly apparent to the user, the
translator must perform both
quickly
and
gracefully
(i.e.
it
not leave a mess on the screen en route to completing the
should
translation).
As an aside, we note that it may be desirable to have
the
flavors
translator
provide
buffer is parametrized.
routines
in
all
of
which the target
This would enable us to have bufferless
windows which can view any canvas instead of limiting us to using
buffered
windows
with all normal flavors and bufferless windows
- 57 -
with BACKFLAVOR.
The routine
which
displays
windows
on
the
screen, then, would have to be modified to first check the window
to see if it is buffered.
on
the
screen
as
its
translator
target
routine
parameter.
not
display
it
implemented
is
that
with
the
display's
This arrangement is clearly
superior to what presently exists in JAWS.
was
would
just as it does today; if it is not, the routine
would call the generic
buffer
If it is, the routine
the
The only
reason
it
present structure of having
flavors determine what the target of their translation will be is
so thoroughly built into JAWS that
would
performing
the
modification
have consumed an unacceptable amount of the author's time.
As mentioned above, the
property
of
being
both
translation
fast
and
routine
graceful.
must
each
direction,
pattern
four
pixel by four pixel seed.
a
we
can
represent
J.
Gonzalez
to
the
entire
The translation
routine, then, would consist of replicating this seed
the target area.
trying
Since the pattern is repeated every
four pixels in
as
the
These goals are
particularly easy to achieve in our case since we are
produce a constant pattern.
have
throughout
To do this, we employ an algorithm developed by
which
expands the pattern geometrically throughout
the target area first
horizontally
and
then
vertically
(Fig.
3.3).
Because our translator must be compatible with algorithms that
seek to display only part of a window, the algorithm we use in
- 58 -
PROCEDURE
makepatern(pterr,
[offset
width, eigt,
<- i(witdth of pttera)
area)
WHILE offset < width DO
[if 2
offset < wiAdth then.
rem <- offset
else
rem <- widt. - offset
(draw potterr
On area tt offsetr,0 in a rectangte of
heg t ecunlto ptern
hetght Lv widtheual to rem)
offset <-
2 < offset]
<- (he-igtt of pattern)
offset
WHILE offset < heigt
[i
2
offset
rem <- offset
else
rem <- height
DO
then
higkht
- offset
(dr.w pttern. on.area at 0,offset
height eqtual to rem aA wtidlt ea.l
offset
Fi9.
3.3 --
<- 2 < offset
The algorithm
area.
]]
for spreading
-59-
. a rectangle
of
to width)
a pattern across a rectangular
BACKFLAVOR's translator
must
pattern
point
at
any
given
be
able
in
the
to
match
To do this, we must
algorithm
Figure
shown
in
3.4.
enhance
The
idea
enhancement is to calculate where we are in the
whatever
pattern
component
at
that
of
Gonzalez'
behind
window
the
and
use
the seed is appropriate for matching the
point in the window.
Since BACKFLAVOR has been successfully integrated
we
existing
window without causing a
visible seam to appear.
as
the
into
JAWS,
have been able to compare its performance to that of the more
traditional implementation of the background
found
that
performance
for
of
the
pattern.
We
have
JAWS
most part it does not adversely affect the
programs.
The
only
time
it
makes
a
noticeable
difference to the user is when he is dragging windows
across the
screen.
dynamically
behind
Because
the
the
background
we
gain
being
In
most
cases,
has
the
is worth this small loss in time; in the case of
the background pattern, our previous storage consumption
bytes
filled
dragged window, the dragging process is
noticeably, but not unacceptably, slower.
space
is
been reduced to one word.
- 60 -
of
96K
CHAPTER
4
CHILD WINDOWS
This
chapter
compares
the
relative
advantages
and
disadvantages of having child windows share the screen buffers of
their parents and having child windows maintain their own
buffers.
we
must
Before
define
we proceed to compare the two implementations,
what
a child window is.
A child window (Fig.
window.
screen
4.1) is a window defined within
another
The window which contains a child window is referred to
as being the child's "parent".
twofold:
(1)
The
child
The implications
window
cannot
outside of its parent and (2)
whenever
child
it
must
both
move
within it (Fig. 4.2).
with
of
possible).
their
this
are
be larger than or move
the
parent
moves,
the
and maintain a constant offset
Recall from the introduction that children
can view canvasses separate from
children
of
own
(so
their
several
parents'
levels
and
of
can
have
children
are
We termed a window with no parent to be a "top-level"
window.
The original implementation of child
children
to
windows
did
allow
have their own screen buffers; instead, they shared
their top-level ancestor's screen buffer (Fig. 4.3).
that
not
This meant
when the canvas of a child window was being translated, the
target buffer
of
the
translation
ancestor's screen buffer.
was
the
child's
top-level
We lose in several ways here.
First,
all of the window management routines which have to handle screen
buffers must become more complex to properly handle child windows
in addition to top-level windows.
Second, we lose the ability to
- 61 -
PROCEDURE bcktrans( wtadoW, qrc)
[(4rec crrites
intformatton,abou
mo&dposx = strttIn3
moposy
= starting
mo&wi
mo dg
IF
(mo&posx
=
rea
wtdk h of
= hetgt
of are)
4 = 0)
mo
the aret to be transtaed&:
x coorcdnirte
coorcnose
ND
(mo&posp
mod 4 = 0) THEN
mak _potkerr(wtInciow^.canvus,
moctwtr, modgt
wit
ELSE
x _off <- mo&posx mod 4; poff <- modposy mod 4;
r m
o
b. u.ffer
id <- (wtindow's c vas widk h - x off)
rem_-gMt <- (winow'
(use xoff,
p
eitghk
s cuas'
off, rem_wiV, nd
- y_off)
rem hkt to draw
odl p.rt of fhe are
To be trasted&;
whkt's
sometnhtg
hat make._patter cot hkantle)
mak_pttkerr(winow
^
khe
eft is
u as , modwid&- remwid,
.cox
modhkgt
- remtg, wtrlow ^. bufer ) ] ]
Fig. 3.4 -- The translation routine for BCKFLAVOR
must be able to
match the pattern stored in a window's canvas to any
location in the window's buffer without leaving a seam.
-61-
-
I
AM
THE
PARENT!
I AM THE CHILD.
Fig.
. 1 --
n example of a parent-child
relationship.
that the child is viewin a canvas which is
d ifferent
from that viewed by the parent.
-62-
Note
I
AM
THE
PARENT!
I AM THE CHILD.
Fig.
4.2 --
The chi ildwindow both moves
ith and maintains its
offset within
the parent window when the parent is
mo ved.
-63-
WINDOW
I
PREVWIND
NEXTWIND
SCREEN BUFFER
--~~~~~~
CRNUHS
CHILDREN
V-/
I
WINDOW B
PREVWIND
NEXTWIND
SCREEN BUFFER
/
/
/
CANVAS
CHILDREN
Fig. 4.3 -- The original implementation of child windows forced children
to share screen buffers with their parents.
Here, WINDOW B
is the child of WINDOW
and as such must use its screen buffer
Note that WINDOW B does, however, view a canvas which is
different from that viewed by WINDOW A.
-64-
have overlapping child
inherently
requires
windows
some
since
buffering.
the
overlapping
Finally,
feature
unless
we are
willing to add yet more special-case code, we lack the ability to
update a top-level window with children
children's screen images.
implementation
of
some
of
is
the
without
destroying
the
Another important disadvantage of this
that it forces the perversion of the meanings
window
operations.
For
example,
the
bury
operation cannot be performed on a child window since a child has
no screen buffer.
Therefore, if the bury operation is invoked on
a
it
child
window,
will
result in the burial of that child's
top-level ancestor.
The alternative to the above implementation is
child
window
hierarchy to
code,
and
its
own
become
keeps
definitions.
fully
buffer.
recursive,
give
This allows the window
eliminates
special-case
The only disadvantage to this implementation is its
machine,
valuable resources.
Depending on the
allocating
a
screen
architecture
buffer
of
may
the
consume
Since child windows are often used to divide
a larger window into several small regions, allocating
buffer
each
the window management operations true to their
potential inefficiency.
underlying
screen
to
for
each
a
systems
child
a
screen
may be unacceptably inefficient in some
cases.
From
design
perspective,
then,
the
implementation is much more appealing than the first.
implementation, however, has its characteristics
- 65 -
for
second
The first
some
very
good reasons (as we have seen).
Some
obvious
solutions
implementation
application
and
are: use either the first or the second
accept
programmer
for each child
determining
he
How do we resolve this conflict?
their
give
the
a choice between the two implementations
makes;
employ
or
a
whether
shortcomings;
not
some
intelligent
method
screen buffer is necessary on a
child by child basis (this is essentially equivalent to what
programmer
immediately
eliminate
the
first
shortcomings in our system.
it
the
would do in the previous proposal only now it is done
automatically and without the programmer's
but
of
is
not
knowledge).
proposal
desirable
since
we
easy
don't
problem.
code
the
the
window
The last proposal is interesting as an
artificial intelligence problem, but still
special-case
fix,
want
application programmer to have to know details about
system's implementation.
can
since we don't want
The second may do as an
really
We
problem
and,
leaves
potentially,
the
us
with
the
segment use
It does, however, preserve the meanings of the
window
management operations and allow the implementation details of the
window
system to remain hidden.
Our work in this area went only as far as
windows
with
their
own
screen
buffers.
researchers will develop techniques
intelligent
solution outlined above.
for
- 66 -
implementing
Perhaps
implementing
the
child
future
more
CHAPTER
5
BUILDING A BRIDGE BETWEEN POLITE AND JAWS
This chapter is concerned with the development of an interface
between POLITE (a real-time editor/formatter) and
was
originally
Prager).
370
the
POLITE
implemented on the IBM 370 under CMS (Borkin and
We are now in the process
to
JAWS.
of transporting
it from
the
PERQ minicomputer where it will require some window
management system to allow it to make use of the APA capabilities
of the PERQ without being substantially redesigned.
to
model
the
POLITE
system
is as a powerful
For that task,
needs a window management system such as JAWS (Fig.
Since there are two major parts to POLITE, the user
manager
(referred
to
in
ref.
as
the screen
document manager, we first consider
user
way
text manipulating
device which has no way to control an APA screen.
it
A good
5.1).
interface
manager)
how features
and the
of the
POLITE
of
interface are supported by JAWS and then discuss the design
the
interface
document
between
representation
the
and
manager
JAWS'
of
POLITE's
display
internal
mechanisms.
The
material presented here is not intended to be a recipe for making
an editor/formatter.
when
they
Details about POLITE
are
mentioned
only
responsible
for
affect its interface to JAWS.
THE POLITE USER INTERFACE
The
POLITE
monitoring
(actions
user
user
input
include
manipulations)
interface
to
both
and
manager
performing
screen
execute
the
is
the
correct
actions
and
document
manipulations
user's commands.
- 67 -
The screen
Fig 5.1 --
POLITE needs to use JAWS to interact with the APR screen.
The screen interface and the buffer manager each use JAWS
for different purposes.
-68-
interface relies on
management
JAWS
functions
as
for
both
input
support
and
window
discussed below.
ENTERING USER REQUESTS INTO POLITE
User requests are related to POLITE in one of two
user
either
of
The
enters the command via the keyboard in some command
area or he selects some command from a menu.
result
ways.
In both cases, the
the user action is that a command string is presented
to the POLITE parser, parsed, and finally executed by the
command interpreter.
The syntax for the commands on the
POLITE
menu is
exactly the same as that for those entered into the command area.
This
menus
leads
naturally
containing
desires.
If
a
the
to allowing the user to modify and create
commands
command
(complete with
arguments)
he
is entered but requires more arguments
than those which were given, the POLITE parser will wait to allow
the user to enter more arguments before it terminates the
This
prevents
the
user
from
being forced to retype an entire
command just because he forgot an argument or entered an
argument.
This
also
parse.
invalid
allows the user to put partially complete
command strings in the menus he creates, thereby increasing
feature's flexibility.
- 69 -
that
HOW POPFLAVOR SUPPORTS THE POLITE MENU SYSTEM
The POPFLAVOR canvas (Chapter 2) in JAWS supports
menu system in several ways.
the
POLITE
First and foremost, it supports the
dynamic creation and modification of pop-up menus.
This facility
allows POLITE to support the menu change feature with very little
code and little data structure complexity (since JAWS handles all
of
the
messy
details of managing the menu data structure).
second way in which POPFLAVOR supports the POLITE
is
by
giving
the
name.
of
a
POLITE
facility
for
Finally, by allowing menu entries to have multiple fonts,
gives
example,
graphically
and
implementation
the user to name menus and subsequently request them by
POPFLAVOR
For
facility
application a name for each menu it creates.
This simplifies the
allowing
menu
A
the
POLITE
POLITE
the
can
menu system increased flexibility.
use
multiple
fonts
to
indicate
difference between the command part of an entry
the argument part.
POINTING AT POLITE OBJECTS
Some commands
commands".
"delete".
they
are of the class
This
class
referred
includes
such
to
as
the
commands
"pointing
as "move" and
The reason they are called pointing commands is
that
require the user to indicate (or "point at") the object, or
unit of text,
he wants
to
move
or
delete.
Objects
anything from the entire document to a single character.
implementation
of
POLITE
is
can
be
The CMS
compatible with the 3270 terminal
- 70 -
family and uses cursor movement keys to allow the user
at
objects.
pointing
The
via
an
to
point
PERQ implementation should be able to support
APA device such as a tablet or mouse.
MAPPING SCREEN COORDINATES TO CANVAS COORDINATES
Correlation of points on the
with
pieces
of text (i.e.
the JAWS window manager.
easily
find
out
what
screen
this
This
window
allows
POLITE
also
a
selected.
the
has
a
technique
facility
text
and
to
selection
to
be
(called
for marking blocks of text as
This facility is powerful enough to
easily
allow
the
indicated, yet is still
the
determination
extent of the selection to be left up to the application
(in this case, POLITE).
determine
A
POLITE
low-level enough to allow the rules governing
of
quickly
is discussed below.
being selected.
of
to
the user is pointing at and what
The canvas we propose to use to support
extent
coordinates)
coordinate with a point in the internal document
representation
TXTFLAVOR)
bit
character coordinates) is handled by
character within that window he has
correlate
(i.e.
the
POLITE uses this selection capability to
arguments for the pointing commands.
- 71 -
HANDLING KEYBOARD INPUT
The question of how to determine the extent of a selection can
be solved in
difficult
a
straightforward
question
is
how
manner.
to
A
editor
buffer
modes: "insert" mode and "replace" mode.
allows new text to be
existing
but
text;
more
handle keyboard input.
We normally modify the contents of an
different
related
entered
without
erasing
in
two
but
Insert mode
relocating
replace mode allows existing text to be modified
without being relocated.
The actual placement of the entered text onto the screen is no
problem: we simply
character
determine
the
cursor
location,
place
the
into the canvas at that point, and let JAWS update the
screen as it normally does after a
canvas
changes.
The
major
problem we face is in determining where in the buffer the entered
text
belongs.
For
within the POLITE
this
system
purpose,
which
buffer coordinates (Fig. 5.2).
given
below.
Given
that
there
maps
must be some manager
canvas
coordinates
into
More detail about this manager is
we have such a device, we can easily
create temporary buffers to hold the user's keystrokes along with
their ultimate destinations until we decide
to
enter
the
text
into the buffer.
A related issue is determining how the screen appears
user
as
character
he
types.
In
he enters appear
as the character
beneath
to
the
replace
mode, the user should see the
in place
of and in the same
his cursor
- 72 -
(assuming
attribute
that all fonts used
Fig 5.2 -- The buffer/canvas
face to correlate
The POLITE buffer
necessary when it
map is used by the POLITE screen intercanvas coordinates with buffer locations.
manager fills and updates the map as is
updates the JAWS canvasses.
-73-
are fixed-width); TXTFLAVOR's TXTCHAR command supports this.
insert mode, the user should see the character he
enters
In
appear
the cursor and the character that was previously beneath
beneath
the cursor move to the right.
But what happens to the character
the end of the line?
One solution is to wrap that character
around to the next line.
Since this may cause that line to spill
at
also, this process must be repeated for each line in the canvas.
This approach works well for fixed
they
contain
a
relatively
small
font
amount
canvasses
(provided
of text), but is not
appealing for a multiple font canvas for the following reason.
multiple font canvas must be laid out bit-by-bit to have
its
lines
be
justified;
spilling
all
A
of
a character
from one line to
another may very well upset this justification.
The solution we
chose is to have TXTINSERT (the character insertion routine) work
only if there is room on the current line for one more character.
If
there
is
not,
TXTINSERT indicates this to the application.
The application then has the option of opening more space in
canvas
by
using TXTBRKLINES.
This routine simply inserts just
the right amount of space in the canvas to
beneath
the
cursor
cause
to appear one line lower.
characters to be placed into the canvas
previous
the
justification of the text.
- 74 -
without
the
character
This allows new
disturbing
the
SUPPORTING THE DOCUMENT MANAGER
need
The POLITE document manager's primary
is
for
font text canvas (TXTFLAVOR) provides the means
translating
To see how,
character/attribute combinations into bit patterns.
look
the
The JAWS multiple
screen understand the characters it puts out.
let's
have
to
more closely at the document manager's operation.
THE BUFFER STRUCTURE AND OPERATION
POLITE text is stored as a hierarchical structure to
To produce the proper
work done to effect a format change.
the
minimize
text layout from this representation, a formatter interprets
combined
one
combinations,
character/attribute
codes
what
into
representation
with
TXTFLAVOR
canvas
being formatted (there can
canvasses
viewing
model
which
are
as
a
character
simply
The receiver of
other
is
be
data
of
stream
attribute control information (e.g.
color, underlining, spacing).
whatever
can
the
this
font,
is
stream
viewing the part of the document
more
than
The
one).
idea
is somewhat alien to
structures
JAWS, but is really no different from that of a window viewing
canvas.
In
this
case,
the
it
is
knows
only
receiving data from its application.
The stream model discussed above is
that
a
information relating canvasses to
documents is maintained by POLITE; the window system
that
of
somewhat
inefficient
in
it requires each character to have a full set of attributes
associated with it specifying how it is to be
- 75 -
printed.
A
more
model is the "ink" model, where we choose an ink color
efficient
attribute specification), write some
(i.e.
in
characters
color, change colors, write more characters, and so forth.
that
This
takes advantage of the similarity of adjacent characters.
TXTFLAVOR supports the ink model with the
routine
TXTCHGATTR
is used to change the attributes in effect starting at the
which
present
location
within
the
and
canvas
extending
the
for
indicated number of characters.
Characters are written using the
needs
to know only the character to be
TXTCHAR
routine,
which
written and the spacing to be left between it and its
determines
looking
at
what
TXTCHAR
the
assign the character by
to
attribute
neighbors.
attributes in effect in the rest of the canvas.
MAPPING A CANVAS COORDINATE INTO A BUFFER COORDINATE
still
We have solved the output problem quite handily, but we
must handle text input by directing it to the correct spot in the
correct document.
This problem was touched upon several times in
sections,
previous
considering
its
but
cannot
be
canvas.
into
a
into
a
canvas
and
easy
a character
The remaining task is mapping that
document
without
implications.
As was indicated above, it is fairly
coordinate
fully
solved
location.
For
map
a
screen
offset within that
pair
canvas/offset
this we need some table which
provides information on what part of what
- 76 -
to
document
each
canvas
views
and what document locations selected points in each canvas
correspond to.
calculate
Armed with
the
exact
this
information,
we
document/document-location
can
quickly
pair
corresponds to the canvas/offset pair we received from
correlation
routine.
which
the
JAWS
Since this table would have to be updated
whenever a canvas is being filled or modified, the responsibility
for maintaining the table should lie with
the
formatter.
This
should be quite easy for the formatter to do since it has all the
information
necessary
it knows where
at hand when it is filling a canvas (i.e.
it is in the document
and
where
it
is
in
the
canvas being filled).
Using the above technique, we can monitor the
and
always
upon.
know
We can
appropriate
location.
user
it
the
then
user's
actions
exact location he is indicating or acting
buffer
his
character
input
and
at
the
time place it in the correct document at the correct
The phrase "appropriate time" is
interface
determined
by
the
portion of POLITE and the issues associated with
which were discussed previously.
THE BENEFITS OF USING JAWS WITH POLITE
The APA capability of
interface
by
allowing
the
more
PERQ
enhances
the
user
rapid user pointing, more flexible
menus, easier menu selection, etc.
power
greatly
But
more
importantly,
the
of the JAWS window management features makes POLITE's code
- 77 -
on the PERQ simpler than its code on CMS even though its function
is greater.
Furthermore, we must realize that JAWS does not make
any special concessions to POLITE.
to
POLITE
are
useful
to
other
The features that are useful
applications
as
demonstrated by the existence of the 3270 emulator
the
graphic
editor mentioned in the introduction.
- 78 -
well
as is
(O'Hara)
and
CONCLUSION
The
techniques
and ideas described
in this thesis
are useful
not only for JAWS, but also for other window management
systems.
The author hopes that the efforts spent on this research will not
have
to
instead
be
repeated
will
be
by
future
window
system designers, but
used as a basis for developing new ideas.
One area for future work is the implementation of the multiple
font formatter design outlined in Chapter 5.
provide
a
Such
This
will
interface really is.
very
difficult
different
should
fairly stringent test of JAWS usefulness.
Another area for future research is moving JAWS
machines.
work
to
machines
reveal
how
different
machine-independent the JAWS
We strongly suspect that it
make
to
will
be
a JAWS application run successfully on
once they are running JAWS.
Other areas which we might investigate include support
general-purpose
not
graphic
flavor
and
input (e.g. handwriting).
- 79 -
support
for
a
for non-character
APPENDIX A
DISPLAY ALGORITHM RESULTS AND ANALYSIS
Appendix A (Display Algorithm Results and Analysis)
Table
Al.1
contains the running times of four different test
application programs each of which were run three separate
using
times
the three different screen management algorithms described
in the text (see Chapter 1).
MPF
always
runs
in
The results are adjusted
so
that
time one while the others take either less
than or greater than time one depending on their relationship
to
the MPF time.
The following is a description of each of the four application
programs used in the testing :
1.
WINTEST1 surfaces eight windows and then
reverse order.
the
them
in
Figure Al.1 shows the display after WINTEST1 has
completed its surfaces, Figure
through
buries
A1.2
shows
the
display
midway
the bury operations, and Figure A1.3 show the display at
completion of the bury operations.
2.
bottom
3.
WINTEST3 surfaces two overlapping windows
window
across the screen (Figs.
and
moves
the
A1.4, A1.5).
QUIXTEST surfaces two overlapping windows and draws
lines
into both windows simultaneously at the rate of several lines per
- 80 -
PROGRAM
DNA
DNRSB
MPF
WINTEST1
.95
.96
1
WINTEST3
.82
1.23
1
QUIXTEST
1.43
1.22
1
WINTEST4
.76
1.07
1
Table H1.1 -- Runningtimes of four test programs under the three
different screen manaqement alsorithms.
Note that
the running time under MPF is normalized to one.
-81-
I
I.=-.
-
-
I Fi9.
1.1
--
WINTEST1
a;fter
it has completed its in i t i al surfaces.
-
I
I
-
--
II Fig.
1.2 -- WINTEST1midway through its bury operat ions.
II
I Fig. A1.3 -- WINTEST1at the end of its bury operat ions.
Fig. A1.4 --
The two overlapping
windows
-85-
in WINTEST3.
Fig.
1.5 --
WINTESTBmoving the bottom window across the screen.
-86-
second
(Fig.
update
the
4.
A1.6).
screen
The
burden
quickly
is
on the screen manager to
enough to match this rate.
WINTEST4 surfaces three non-overlapping windows and writes
text
into
the
canvas
they
all
share.
Since
they all view
different portions of the canvas, the writing appears in them
different times (Fig.
at
A1.7).
There are two major criteria by which we can estimate the time
performance of each of these screen management algorithms:
adeptness
at handling the update of an overlapped window and the
amount of overhead they generate when handling
cases.
even
the
simplest
cases
to
take
performing twice as many writes as do the
writes
to
redisplay
analysis
longer
other
by
always
algorithms
(it
the shadow buffer and then to the screen).
Since the focus of our attention is the
our
simple
An example of such overhead is provided by DNASB since it
causes
first
their
performance
of
MPF,
consists of comparing each of the other algorithms
to MPF for each of the test programs.
This is the reason we have
chosen to normalize the time taken by MPF on each test program in
Table Al.1.
WINTEST1
WINTEST1 is the
most
complex
of
the
four
test
programs.
Accordingly, we expect it to be the most demanding to MPF.
- 87 -
Since
F i g. R1.6 --
QUIXTEST drawin9
lines
into
two overlapp i n
windows.
I
FTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT.
)yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
..........................................................
WU~~~vUUUUUU9WUUUU9UUU~~~~~~~~~~~~vUUU9WUUUUU99~.......
............ ........................
::: ................
11i!||!~~~~~~~~~~~~~~~iCF~ThZ
.......
~~~~~~~~~~~~~~~~~.HH.............................
.........
.....
.....
RARRRRAGRARARRAGRRARARARAR....................
III
........................
.BB....
B
.....................................
..........
K KFFNNN
K ..........
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FF
........
n > > of o ~~~~.
o>fof>.
...........................
o>oo>oooo>>o.
21
JJ J Su
S J J JS J J J J J J J J J J J J J J J ~~~~......
S ...........
...'.................
|.......5..
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHPPP
IEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
MMMM
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
BBBB
....
TTTT
333m33
4
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL3
IMMMMM[MMMMMMMMMMMMMMMMMMMMMMMMMMM
JNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
33UUUU3,.
,3'.3,33.
yyyyUW
)0000000000000000000000000v003
3.33.3...333. 3..
,.3,333,,33
.PPPPPPPPPPPPPPPPPPPPPPPPPPPPP
.............
!QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ3
,..,3333'333,,
3BBBBBBRBBBBBBBBBBBBBBBBBBBRBBpBBR
)DDDDDDDDDDDDDDDD
DDDDDDDDDDe~oooo
31
333.333L33
7TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
333....33.
Juuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu:000
5 1n''l
11 Se ='u=='
Fig. A1.7 -- WINTEST4
allows
1i'l::
3.
,,,,,., ..... .j.
333
.3333
3.333....3333.
.3.3
3.33
j4S
;three windows to share the same canvas.|
DNA
involves
a
minimal
amount
of
processing prior to screen
writing, we expect it to run faster than MPF,
great
deal
of
preprocessing,
does.
depends on how many bits it writes to
(i.e.
how
many
How
the
which
involves
a
much
faster DNA is
screen
unnecessarily
are written only to be overwritten in the
bits
This figure is in turn determined by the degree of
same update).
overlapping present in the screen area to be redisplayed; that is
the ratio of the
area
being
redisplayed
to
the
affected areas of each window to be redisplayed.
sum
of
the
This ratio, the
"overlap ratio", is proportional to the difference in performance
between a "thinking" algorithm (such as MPF) and a "non-thinking"
one
(such as DNA).
If the ratio
is small, then there
deal of writing time to be saved
bits;
if
it
is
by
not
unnecessarily
In
ones
are
the
case
overlapping
of
WINTEST1,
(Fig.
Al.l).
we
This
observe
means
that
a
high
the
overhead
of
degree
of
non-thinking
by
writing
although they do not incur the
Therefore,
unnecessarily.
preprocessing
determining
necessary and which ones are not.
algorithms (DNA and DNASB) should all be bogged down
bits
writing
large, then there are not that many bits to be
unnecessarily written, so one may as well not bother
which
is a great
MPF,
they
lose
time
because
of
unnecessary writes and in the end take almost as much time as MPF
does.
This
is
verified
by Table Al.1.
One may expect that DNASB would take much more time
since
it
does
more
bit writing.
- 90 -
than
DNA
But once again, the overlap
ratio comes into play to tell us that
screen
the
(from
shadow
buffer
the
extra
write
to
DNASB) is negligible when
in
compared to all of the writes done anyway be both DNA and
very
Therefore,
indicated
little
extra
the
time
taken
is
DNASB.
by DNASB (as is
by Table Al.1).
WINTEST3
In WINTEST3, we note that the ratio
throughout more than half of the test, there is
suggests
that
the
much
is
This, when coupled with the fact that
than in WINTEST1.
higher
overlapping
of
algorithms
perform significantly better
overlapping,
the lowest overhead should
with
than
no
the
algorithms
with
higher
overhead.
The lowest overhead
The test results do, in fact, show this.
for
algorithm
configurations
non-overlapping
and
simple
configurations (i.e. configurations with a high overlap ratio) is
DNA; it performed
belongs
writes
best
on
this
test.
The
highest
overhead
to DNASB (because the high overlap ratio makes its extra
more
algorithm
significant);
on
this test.
accordingly,
it
is
the
MPF's preprocessing actually costs it
time on this test since the time spent trying to save bit
is
greater
again,
writes
the time saved by not writing those bits (once
than
because
slowest
of the high overlap ratio).
- 91 -
QUIXTEST
QUIXTEST
is an example
analyze.
The
area
of a
of
good
configuration
overlap
is
configuration simple enough to make the
large
time
for
enough
MPF
spent
to
and
by
the
MPF
in
preprocessing less than the time it would have taken to write the
unnecessary
bits.
This
allows
MPF to outperform both DNA and
DNASB significantly.
WINTEST4
WINTEST4
demonstrates
low-overhead
algorithm,
high-overhead algorithm.
the
a
disparity
in
by
a
algorithm,
and
a
medium-overhead
performance
In this
case,
DNA
has
no
overhead
whatsoever since it does no preprocessing and there are no wasted
bits
(compare to WINTEST3 where there were, in fact, some wasted
bits to keep DNA's
time
overhead
it has to determine that there is no need for
in
that
high).
MPF
has
a
small
amount
of
preprocessing (this determination is, in and of itself, some form
of preprocessing).
of
doubling
the
DNASB, of course, has its constant
overhead
writes it must do.
In analyzing the results of such tests, we must keep
that
there
is
a
vast
cannot
expect
some price in time.
mind
difference in the quality of the screen
management provided by DNA and that provided by
We
in
MPF
and
DNASB.
to receive such an improvement without paying
This being so, it
- 92 -
is
somewhat
remarkable
that
as
in
half the tests, the non-flickering algorithms performed
well as or better than DNA.
Another point brought out by the test results is that although
MPF outperforms DNASB in every configuration of simple to
complexity,
DNASB
configurations.
does
have
the
edge
in
the
more
medium
complex
This emphasizes the point made in Chapter 1 that
a simple complexity test with little overhead could enable us
to
achieve good performance in all cases by selecting MPF when it is
the
appropriate
algorithm
and DNASB when it is not.
- 93 -
REFERENCES
(Borkin and Prager)
Borkin, S.A., and Prager, J.M., POLITE Project Progress
Repqort, IBM Cambridge Scientific Center Report G320-2140,
IBM
Corp.,
April,
1982.
(Gonz)
Gonzalez, J.C., Iplementing a Window System for an All
Points Addressable Display, IBM Cambridge Scientific Center
Report G320-2141, IBM Corp., December, 1982.
(O'Hara)
O'Hara, Robert P.,
AIDE
Environment,
IBM
Corp.,
An
Interactive
September, 1982.
DispElY_
(PERQ)
Three Rivers Computer Corp., PERQ Software Reference Manual,
Pittsburgh,
(Tesler)
Tesler,
Pa.,
Larry,
Publications
1982.
"The
Inc.,
Smalltalk
August,
Environment",
1981,
vol.
6
Byte,
num.
Byte
8.
(Weinreb and Moon)
Weinreb, Daniel, and Moon, David A., Introduction to Using
the Window System, M.I.T. Artificial Intelligence Laboratory
Working Paper 210, May, 1981.