Download Segments on bit mapped graphics displays

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
SOFTWARGPRACTICE AND EXPERIENCE, VOL. 16 (1 l), 965-980 (NOVEMBER 1986)
Segments on Bit-mapped Graphics Displays
MEL SLATER
Department of Computer Science and Statistics, Queen Mary College, (University of
London), Mile End Road, London El 4NS, U.K.
SUMMARY
The problems associated with using picture segments in interactive applications on workstations
with bit-mapped displays are discussed. A method for displaying and updating segments is
introduced.
KEY WORDS
Segments
Display file
Bit-map
GKS
1. INTRODUCTION-PICTURE
SEGMENTS
Computer graphics packages which have their origins in the 1970s (or earlier) such as
GINO,’ CORE2 and GKS3,4provide picture segments as the means of defining and
manipulating separate components of an overall image. A picture segment is defined
as a group of graphical output primitives, such as lines, polygonal fill areas and text.
An output primitive is generated by a call to a graphical output function provided by
the package. For example, when a segment is created in GKS, subsequent calls to the
graphical output functions (such as Polyline, Fill Area and Text) are written to the
segment, until the segment is closed. The applications program provides a name for
each segment, which can then be used as a handle for manipulation.
A segment can be highlighted, made visible or invisible, or be transformed by an
affine transformation. This provides the means for creating an image in a structured
manner, made up of a number of separable parts. In addition, in an interactive system,
a segment can be picked-that is, a function is provided whereby a segment can be
identified and its name can be returned to the applications program. (This type of
input is called Pick Input in GKS). For example, an operator might use an input
device to point at a segment’s representation on the display, in order to identify a part
of the picture to be modified. Dragging can be achieved by repeatedly applying a
transformation which specifies a translation in accordance with the movement of a
cursor. These ideas are illustrated in Figures 1 and 2, which were created interactively
using GKS.
Such picture segments have historically been attractive in computer graphics because
of their direct correspondence to vector refresh display architecture. Here the image is
actually represented in the graphics device as a segmented display list of vectors.
0038-0644/86/110965-16~08.00
0 1986 by John Wiley & Sons, Ltd.
Received 18 September 1985
Revised 7 March 1986
966
M . SLATER
Fig. 1
I
Segments
1
x
Figure I . Segments: each image component is a single segment
are usually created
in applications p r o g r a m s
as follows:Createsegment( 1 ) ;
11'
CloseSegment
Polyline & Text
are 2 of the GKS
output primitives
Figure 2.
Segments in the device display list correspond exactly to the high-level segments
defined in an applications program. T h e refresh cycle involves cycling through the
display list, continually regenerating the screen image at a rate fast enough to give the
SEGMENTS ON BIT-MAPPED GRAPHICS DISPLAYS
967
impression of immediate changes to the picture. For example, the instruction to rotate
a segment would result in an immediate change in the orientation of the segment’s
screen representation.
This type of system and display architecture proves especially suitable for engineering
CAD applications, where technical drawings are composed of vectors (and charactersalso constructed from vectors). Changes to the drawing, such as repositioning, scaling
or rotating objects, can occur at a speed fast enough to allow a genuinely interactive
means of technical design.
Modern single-user workstations usually provide a bit-mapped graphics display,
where the screen is refreshed from a (rectangular) array of bits with one bit per pixel.
Graphics programming is based on a rasterop primitive which is a copy operation
combining a source rectangle with a destination rectangle according to a bit combination
rule. Functions are provided which allow easy construction of basic tools used in
interactive graphics-such as rubber-band techniques, pop-up menus and icons. Together with a suitable input device, such as a tablet and puck or mouse, such systems
attempt to provide a total computational environment. The original work carried out
at Xerox PARC resulting in Smalltalk-805@is the fundamental model for such systems.
Bit-mapped displays are very good indeed for manipulating images at the pixel and
rectangle level. However, the concept of a picture segment remains a valuable highlevel representation, corresponding to the way a graphics programmer might think
about how a picture is to be constructed. This is especially the case in CAD: pictures
are composed of vectors, and groups of vectors represent meaningful components which
are a basis for interactive manipulation. However, there is a conflict between the highlevel segment representation and the device architecture. T h e device stores a picture
as a bit-map, whereas a segment is a sequence of geometrically-defined graphics
primitives. The direct mapping between the picture description in terms of segments
and the device method of representing the screen image is totally lost.
As an example, the instruction to set segment S to be invisible would require a n .
identification of exactly those pixels corresponding to S. These pixels must be switched
o f , but pixels corresponding to other segments which might be near or overlap S must
not be affected. Obviously, this operation is computationally possible-but rather slow.
The use of segments on bit-mapped displays has been seen as equivalent to abandoning
the speed necessary for interaction with meaningful components of the picture. If a
segment cannot be dragged or rotated in real time, then it is no longer a means of
dynamic manipulation, but simply a data structure providing a high-level picture
description.
Graphics standards such as G K S insist on the segment as the basis of picture
construction, even though bit-mapped and raster displays are cheaper and in greater
use than the old-style vector refresh devices. Project managers faced with the conflicting
demands of using standards wherever possible and relying ‘on equipment which cannot
support graphics standards efficiently are left with a difficult choice, which sometimes
leads to the decision to abandon the graphics standards altogether.
The purpose of this paper is to show that it is possible to use segments on bitmapped devices in interactive applications. The objective is to provide an algorithm
which allows dynamic changes to bit-mapped displays, where segments are used as the
means of picture description. The algorithm must be as fast as possible.
@ Smalltalk-80 is a trademark of the Xerox Corporation.
968
M . SLATER
2.
DYNAMIC CHANGES ON BIT-MAPPED DISPLAYS
There are several responses to the problems associated with segments on bit-mapped
displays. The first is to ignore this approach altogether and construct algorithms and
software based on what these displays are especially good at-manipulating rectangles.
For example, Pike6 describes a toolkit based on (overlapping) rectangle primitives.
Cook7 describes an algorithm for fast movement of (overlapping) rectangular objects
(such as images of playing cards) around a display. The Smalltalk approach, based
essentially on rasterop and bitwise-governed graphics primitives (e.g. drawing lines
and curves using the Exclusive OR combination rule), has provided good-quality
graphics on bit-mapped displays. T h e drawback is that it is not possible in these
systems to escape from the essentially rectangular limitation, It is thus not possible to
achieve genuine scaling of an object (except by blowing up pixels) or rotation (except
through right angles). There is no possibility of defining and interacting with arbitrary
geometrical objects.
A second method for dealing with segments on bit-mapped displays is to treat
segments as a storage data structure only. This is the method implicit in G K S for
dealing with segments on devices which cannot perform dynamic modifications to an
image efficiently. When in such an interpretation a segment is, for example, rotated
by a call to the Transform Segment function, the screen image does not necessarily
immediately change to show the segment in its new orientation. In fact the effect of
the function is purely internal-the transformation matrix associated with the segment
is changed as required, and this new transformation is applied to the geometric
description of the primitives in the segment at the time when the image is next explicitly
updated by a call to the Update Workstation function. Immediate dynamic changes to
a display are not possible-except, of course, displaying new primitives. (GKS also
allows the system to be put into a state where the entire image is redrawn whenever a
dynamic change to the picture is flagged.) This method is clearly not suitable for
interactive work, since it involves redrawing the whole image based on the data in the
segment data structures whenever an update is required. For complex images, perhaps
involving thousands of vectors, the time involved is usually unacceptable.
A third method is to allow ‘dirty’ dynamic changes to a picture. Again segments act
as a storage data structure. When a segment attribute is changed (made invisible, or
transformed) the segment is redrawn using the Exclusive.OR or 0 combination rulewhich has the effect of deleting it from the screen. In the case of transformation it can
then be redrawn in its new position. This approach was adopted by Bramer and
Sutcliffe’ in their incorporation of a segmented display structure for raster devices into
the GINO-F package. Clearly this method will work, and is quite fast (obviously
depending on the complexity of the segment). However, the initial delete operation
will result in intersecting pixels of overlapping segments being set to o f . When the
overall picture gets into too much of a mess, an Update function can be used to redraw
all the segments in the display list. Although this method may be suitable in some
applications, it is not a generally satisfactory solution, both from the point of view of
aesthetics and user interface design. Parts of a picture disappearing must be disconcerting to users of interactive systems. The situation is worse if the segment contains
a fill area primitive. Substantial parts of the image could vanish, requiring frequent
recourse to the Update function.
Another problem with the previous two methods is that the hit detection necessary
SEGMENTS O N BIT-MAPPED GRAPHICS DISPLAYS
969
for Pick Input is very expensive. Given an arbitrary point on the display, usually
chosen by an operator using an input device, the problem is to find which segment (if
any) is being pointed to. The segmented display list must be searched, usually in a
priority order, until a segment is found containing a geometric object which is close
to the point. Clearly, the search time involved for a large display list could be
prohibitive, although Bramer and Sutcliffe give some test data showing that acceptable
timings can be achieved.
A fourth and more sophisticated method was used by Warner and Keifhaber’ and
also described by Foley and Van Dam.” Part of the description of a segment is its
extent, which is the smallest bounding rectangle enclosing all of the segment primitives.
Now when a segment S is transformed the following operations are carried out:
(a) Clear the pixels in the extent of S. This should be a fast operation, since it can
be done using rasterop.
(b) Redraw all segments which have extents which overlap the extent of S (and
using the extent of S as a clipping region).
(c) Redraw S in its new position according to the transformation applied. Clearly,
a new extent would have to be computed.
This method is superior to the ‘redraw everything’ and ‘dirty changes’ approaches. The
whole screen is not necessarily redrawn-only those segments with a possibility of
overlapping S are affected. Rectangular extents are appropriate because clearing a
rectangular area to white area is easy, as is clipping to such an area. Hit detection also
benefits, for segments with extents not including the hit point can quickly be rejected.
However, the method can lead to an entire screen redraw in the simplest of cases.
Suppose segment S includes a diagonal line across most of the screen. Even if no other
segment is close to S, the entire screen will be redrawn-for the extent of S must
include the diagonal line. Similarly, suppose S includes a boundary box enclosing the
drawing. Scaling of the boundary box to enlarge it or make it smaller would result in
the redrawing of all segments.
A final method is to write special-purpose firmware as part of the graphics device,
to maintain a segment data structure. This solution has been adopted, for example, in
the 6000 series graphics terminal produced by Sigmex U.K. Ltd., which embodies a
GKS workstation implemented in 68000 code. When a segment S is transformed the
entire display image is redrawn, with S transformed, into an off-screen buffer. On
completion, this buffer is switched to become the actual display. A similar scheme is
adopted by the STEP graphics terminal produced by the French company AMAIABayonne. (There are no doubt other machines which employ a similar approach.) This
method works because it is embodied in firmware-i.e.
because it is very fast. It
sidesteps the bit-maplsegment conflict, rather than resolves it-though it is clearly a
working solution. There are nevertheless drawbacks. Given a complex image containing
a large number of graphics primitives, redrawing everything can take a noticeable
amount of time even in 68000 code embodied in firmware. This is experienced by the
user as a delay in response to a segment manipulation command. However, this cannot
be held as a genuine criticism of this approach, for even on vector refresh devices,
screen flicker is the cost of displaying images with a large number of vectors. The real
drawback is that this solution is, of course, not portable. It must be reimplemented
from scratch for every new device. Moreover, it cannot help users with existing bitmapped equipment-there is little possibility of adding complicated firmware to interface an existing product correctly.
970
M. SLATER
3.
DESCRIPTION O F T H E METHOD
The objective of this investigation is to provide a method for dynamic changes on a
bit-mapped display, based on the segment concept. T h e method described results in
redrawing only those segments which have a high probability of intersecting the
changed segment S. If no segments intersect S then only S itself is redrawn. In other
words, the speed of the algorithm depends on the local complexity of the picture near
the affected segment. The same is true for hit detection: the speed of this operation
depends only on the complexity of the picture near the hit point. The algorithm is
simple, and the computations involved are almost entirely additions and bit shifts.
Special hardware or firmware is not required to achieve acceptable speed. T h e method
is described in abstract terms in this section, and implementation information is given
in sections 4 and 5. Run-time performance is discussed in section 6 and further work
is discussed in section 7.
The method is based on a division of the display space into a rectangular grid. If
there are ndivx divisions horizontally, and ndivy divisions vertically, then this generates
an ndivx X ndivy grid. For the sake of a naming convention, the grid cells are called
tiles, and numbered from 0 to ndivx- 1 horizontally and 0 to ndivy- 1 vertically. Tiles
will be denoted by t = (t.x,t.y), which is the (t.x,t.y)th tile. For example, the tile at
the bottom left-hand corner of the display is t = (O,O), in which case t . x = t.y = 0.
This is shown in Figure 3.
The basic graphics primitive is assumed to be one which draws a straight line
between two points. This primitive will be denoted by lineZ(pO,pl, seg) where p0 =
(pO.x,pO.y), pl = @l.x,pl.y)and seg is the name of the segment to which the line
(p0,pl) is to be appended.
The essence of the method involves finding the set of tiles intersected by any line,
which will be referred to here as tile conversion. This is similar to the usual process
of scan converting lines into pixels. However, tiles (unlike pixels) maintain information
identifying the segments that pass through them. Hence for every tile which a line
intersects, the corresponding segment-name is recorded in a data structure associated
with the tile. Suppose a segment S is to be made invisible. First, all lines in S are
redrawn using the 0 bit operator (i.e. the lines are cleared). An active segment list is
constructed which consists of the names of all segments which probably overlap S.
This list can be constructed easily, for it will consist of the union of all segment-names
stored at all the tiles intersected by S. All the segments in the active segment list are
then redrawn. If S is to be transformed, it is first made invisible as described above,
and then redrawn in its new position.
The method can be described formally in terms of two main data structures, and a
number of functions and procedures. The fundamental data structures of set, list and
array are assumed. g is used to denote the empty set and the empty list. E is used to
denote both set membership and list membership. The list cons function is denoted
by the infix operator:: Displayspace is used to denote the state of the screen.
Data structures
Let Tiling be an array, where for any tile t,, Tilinglt] is a set of segment-names. Let
Segment be an array where for any segment-name seg, Segmentlsegl is a list of lines.
97 1
SEGMENTS ON BIT-MAPPED GRAPHICS DISPLAYS
0
1
3
2
Figure 3. ndivr
=
4
ndivy
5
=
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20. TileslnLine = {(3,3),(4,3),(4,4),(5,4),(5,5)
,...,(15,11))
A point is described as x and y components (x, y) and a line is described by its two
endpoints. Let S be the set of possible segment-names, and I the set of indices to the
Tiling array.
Basic functions and procedures
function TileslnLine(1ine)
returns the set of tiles intersected by line.
function LineTran(line,T)
returns (Tp0,Tpl) where (p0,pl) = line and Tp0,Tpl are the endpoints transformed by
the transformation matrix T.
procedure DrawLine(line.op)
972
M . SLATER
results in line being displayed on Displayspace, using the op combination rule. The
only two values of op to be used here are 0 and 1, with 0 meaning off and 1 meaning
on.
procedure ClearDisplay
results in all pixels in Displayspace being set to off.
Derived basic functions and procedures
function TileslnSeg(seg)=
U
TileslnLine(I)
IGegment[segl
procedure DrawSeg(seg,op) = for all line E Segment[segl do DrawLine(line,op);
procedure SegTran(seg,T) = for all line E Segment[segl do line := LineTranUine, TI;
Derived high-level procedures
The algorithm can now be described in terms of the following procedure-definitions :
procedure lnitialise =
begin
ClearDisplay;
for all t E l do Tiling[t] : = 0;
for all sES do Segment[sl : = 0
end
procedure line2(line,seg) =
begin
DrawLine (line,l);
for all t€TileslnLine(line) do Tiling[t] : = Tiling[tlU{seg};
SegmentIseg] := line : : Segment[segl
end
procedure SetVisibilityOn(seg) =
begin
DrawSeg(seg.1);
for all t€TileslnSeg(seg) do Tiling[tl : = Tiling[tlU{seg}
end
procedure SetVisibilityOff(seg) =
begin
DrawSeg(seg,O);
for all tETileslnSeg(seg) do Tilingit1 : = Tilingkl - {seg};
U
Tilingrtl
let ActiveSegList =
tETileslnSeg(seg)
in
for all sEActiveSegList do DrawSegts,1)
end
SEGMENTS O N BIT-MAPPED GRAPHICS DISPLAYS
973
procedure TransformSeg(seg.T) =
begin
SetVisibilityOff(seg1;
SegTran(seg,T);
SetVisibilityOn(seg1
end
T H E T I L E S INTERSECTED BY A
LINE
4. T I L E CONVERSION-FINDING
Of crucial importance to the speed of the method is the execution time of the function
TileslnLine, which computes the set of tiles intersected by any line. The algorithm for
this computation is a simple generalization of Bresenham's line-drawing algorithm."
Consider a line joining points p 0 and p l . Let dx = p1.x - p0.x and dy = p l .y p0.y with dx > 0 and dy > 0. Let t O and t l be the tiles corresponding to p 0 and pl.
The algorithm to be constructed is defined recursively. Given an expression for the
tile discovered at the ith step in the execution, an expression is derived for the tile at
the (i+l)th step. Let ti = (ti.x,tj.y)be the tile at the ith step. It is then shown in the
Appendix that if W is the tile width, and H the tile height,
+ 1)
else if f t = 0 then (ti.x+l, ti.y + 1)
else iff;- < 0 then (ti.x + 1, ti.y)
ti+] = if fi> 0 then (tj.x,ti.y
where
fo = dx(p0.y MOD H ) - dy(p0.x MOD W) - Hdx
+ Wdy
and
fi = iff,-l > 0 thenfiP1 - Hdx
else if h-l = 0 then Wdy - Hdx
else if k.- < 0 then J - ] + Wdy
A similar result for the case dy < 0 can be derived easily, and the cases dx = 0 and
dy = 0 can be dealt with separately.
IMPLEMENTATION
The first implementation objective was to test the philosophy of the method. Does it
result in a system where segments can be manipulated in real time-in other words,
does the method support interactive work? The crucial determining factor is speed. As
usual, there is a time versus space trade-off. Therefore, the implementation concentrated on obtaining maximum speed at the cost of allowing the definition of only a
relatively small number of segments. Then a more general version was implemented
to allow a large number of segments.
It should be noted that the problem of hit detection is greatly reduced in the method
of this paper compared to earlier work. The speed of hit detection depends on the
974
M. SLATER
complexity, in terms of numbers of vectors and segments in the region near to the hit
point. This region is, of course, the tile in which the hit point is located. Since each
tile maintains the list of names of segments which pass through it, only this list need
be processed rather than all defined segments. The size of this list depends on the size
of tiles (i.e. on the number of divisions) used. In practice the Tiling matrix is likely to
be sparse, and each tile is likely to point to only a relatively few segment-names
compared to the number of segments defined. Obviously rogue cases exist where every
segment passes through every tile, but the occurrences of these are likely to be rare.
The first decision made in order to obtain maximum speed was to insist that the tile
width and height should each be powers of two, and in fact tiles were chosen to be
square. Therefore in the TileslnLine algorithm every operation becomes either a bit
shift or an addition. The only exception requiring two multiplications is in the initial
computation off.
The set operations specified in section 3 can be implemented easily and nacvely on
lists. Set union can be implemented as an insert function, where an element is inserted
into the list so that the list is maintained in ascending order-in order to avoid the
duplication of elements. Then Tiling is a two-dimensional array of pointers to lists of
integers representing the segment-names. The array size is ndivx X ndivy. Finally,
Segment can be represented as an array of pointers to lists of vectors, where a vector
consists of two points defining the end-points of a line. The Segment array is indexed
by the (integer) segment-names.
The second decision made to obtain maximum speed was to implement the set
operations using actual bit operations on integers. Here unsigned 32-bit integers were
used to represent a set of segment-names. The maximum number of segments allowed
was therefore 32. Set membership, union and difference can be represented by the bit
operations. The Tiling array in this scheme was an array of integers. This set of choices
seems to be especially suitable in applications requiring a small number of segments,
and where speed is of paramount importance.
This can be generalized in various ways. Each element of the Tiling array could be
a pointer to a linked list of pairs of integers, with the first integer in each pair
representing a set of 32 possible segment-names and the second integer representing the
lowest segment-number in the set. For example, if the only segments in the list were
65, 66, 67 and 68 then this would be represented as (30,64) since 30 as a bit map is
11110 and 64 is the largest power of 2 less than or equal to 65. As another example,
the list [(3,64);(248,992)] denotes the set of segment-names [64, 65, 995, 996, 997,
998, 9991.
Alternatively, the sets could be represented as arrays. For example, suppose the not
unreasonable maximum of 1024 segments was allowed. Then each element of Tiling
could be an array of 32 integers, representing a set of maximum size 1024. This would
have the advantage of constant time for set operations on the segment-names. However,
the cost is the large amount of memory required. For example, on the Whitechapel
MG1 workstation'2 on which the system was implemented, using a tile size of 32 X
32 bits causes the dimension of Tiling to be 32 X 25 since the display space resolution
is 1024 X 800. Therefore a total of lOOK bytes was required to store the Tiling array,
which is exactly equivalent to an extra screen full of memory. This seems excessive,
but it must be judged against the advantages that segmentation offers an application.
The demand for large amounts of memory in interactive applications on bit-mapped
displays is not unusual. For example, Cook's algorithm for overlapping rectangles
requires four screen-sized bit maps, although this includes double buffering.
SEGMENTS ON BIT-MAPPED GRAPHICS DISPLAYS
975
6. RUN-TIME PERFORMANCE
Two tests were carried out each on the implementation allowing 32 segments, so that
timing calculations were independent of the particular data structure used for the
elements of the Tiling array. The first test involved drawing 32 curves each in a different
segment. One of the segments contained a Sierpinski curve, and the other 31 segments
Hilbert curves.13 A Hilbert curve of order i is made up of 4’ - 1 short lines, and the
same is true for a Sierpinski curve of the same order. This was to simulate curvedrawing in CAD, where (for example) spline curves are generated by drawing sequences
of contiguous short lines. Figure 4 shows a random arrangement of such curves for
the case i = 4. Timings were taken for rotation and scaling, since these would be the
most computationally expensive operations. The test involved drawing the curves at
random positions on the display, then rotating the Sierpinski curve ten times, and
finally scaling 10 times. This whole operation was itself repeated 10 times. The tile
size was taken to be 32 X 32. When each curve was of order 2 (i.e. containing 15
lines) the overall mean rotation time was 0.08 s, and 0.04 s for scaling. For curves of
order 4 (containing 63 lines) the mean times for rotation and scaling were 0.23 and
0.20, respectively. For curves containing 255 lines the times were 1-12 and 1.16
seconds. Here scaling takes longer, because as the segment grows in size it overlaps
more segments, thus increasing the size of the active segment list. Finally, when each
curve contained 1023 lines, the mean rotation and scaling times were 21.5 and 19.0 s.
All timings were elapsed times, which included background activities such as disk syncs
which occurred every 30 s. These results are summarized in Table I.
Table I . Timings for rotation and scaling of Sierpinski curves
No. of lines in
curve
Mean rotation (s)
Mean scaling (s)
15
63
255
1023
0.08
0.23
1.12
21.50
0.04
0.20
1.16
19.00
A second test involved drawing 32 chess pieces, each made up of approximately 30
lines (including those used for shading). The user could pick any piece by pointing
using a mouse, and then shift, scale, rotate or delete the piece. The program proved
to be fast enough for genuine interactive manipulation of the pieces.
Experience generally suggests that segments of up to about 100 lines can be manipulated fast enough to allow the method to be used in interactive applications.
7.
FURTHER WORK
This paper describes an experimental system for the incorporation of segments on bitmapped displays. The method has proved to be a sound starting-point for further
investigation which is concentrating on the following issues :
(a) The structure of the Tiling array in real applications needs to be studied. It is
likely that the array will be sparse, and the array elements will tend to represent
976
M. SLATER
Figure 4.
sparse sets. If this is the case then a data structure can be employed which takes
account of these features, and which minimizes the amount of space needed. An
optimum solution needs to be found in the trade-off between time and space
requirements.
This paper has concentrated on segments consisting only of lines. Other geometric primitives need to be considered, although the extension of the method
to polygon fill and text primitives is straightforward. For polygon fill the same
algorithm used to scan convert the polygon (such as the Y-X algorithm described
by Newman and S p r ~ u l l ' ~could
)
be used to find the tiles covered by the filled
polygon. In other words when a filled polygon is to be made invisible, the Y-X
algorithm is employed relative to the tiling co-ordinate system, and as each
horizontal row of tiles is discovered it is cleared to white using rasterop. Text
can be represented by vectors, which would have the advantage of allowing full
scaling and rotation. This would be equivalent to the stroke precision text defined
by GKS. Characters stored as bit-maps could also be handled. T h e segment
would store the string of characters, the co-ordinate of the start point of the
string, and any information necessary to compute the smallest rectangle enclosing
the text, such as character height and spacing. This rectangle could then be used
to compute the tiles covered by the character string. Text stored in this way
(equivalent to GKS character precision) can be translated, but not rotated or
scaled.
SEGMENTS ON BIT-MAPPED GRAPHICS DISPLAYS
977
(c) If this method is to be used successfully in a general graphics package, and GKS
serves here as an example, then it has to be fitted correctly into the viewing
pipeline. In addition, the method for storing and accessing the segment-attributes
needs to be specified. This raises the question of how colour is to be incorporated,
thus allowing the method to be implemented for any raster display. This is part
of the more general problem of representing the primitive attributes in the
segment data structures.
(d) A major area for extension is the inclusion of segment priority. GKS allows a
priority to be associated with every segment. This is used both for determining
the order in which segments are redrawn in an update, and the order in which
the display list is scanned during hit detection for a Pick Input. If segments
include only lines, then priority ordering is not necessary in the case of redisplay.
However, once colour and area fills are included then priority becomes important.
This can be handled within the confines of the present method. Let
ASL(s)
U
=
Tiling[tl
tETileslnSeg(s)
ASL(s) is the set of all segments which are (probably) intersected by s (including
s itself), and which need to be redrawn if s is made visible. Now suppose that
a priority is associated with each segment, and that segments must be redrawn
in the correct priority order. Then the Closure of ASL(s) must be found, and all
segments in this set redrawn, where
Closure(s) =
u ASL(i) - {s}
iEASL(s)
This is in order to make s invisible. If this is part of a transformation operation,
then instead of next redrawing s in its new position, a similar closure set must
first be computed at this new position of s, and then all segments in the closure,
including s, redrawn in the priority order.
(e) Experience on the MG1 suggests that a tile size of 32 X 32 or 16 X 16 provides
suitable compromise values (determining the number of tiles as 32 X 25 or 64
X 50). The smaller the tile size, the larger the number of tiles and hence the
greater the execution time for the TileslnSeg function. However, if the tile size
is small then the number of elements in the active segment list will tend to be
smaller, leading to a shorter execution time for redrawing. The relationship
between these parameters needs further investigation.
(f) The method described in this paper is portable in that it can be implemented
on any workstation with a bit-mapped display and which supports the usual line
drawing and rasterop functions. Moreover the testing carried out so far indicates
that it works fast enough for interactive applications. However, there is a certain
amount of inefficiency involved, for every line is actually scan converted t w i c e
in order to discover the pixels it intersects and then again to find the tiles it
intersects. The first scan conversion is necessary for generating the line into the
screen bit-map. This is normally done in machine hardware or firmware. Second,
the tile conversion is carried out by the segment display algorithm. It is probably
worth investigation to see if these two operations can be combined.
978
M . SLATER
ACKNOWLEDGEMENTS
Thanks to Don Beal and Keith Clarke for helpful comments and suggestions, and to
Steve Cook and George Coulouris for commenting on an earlier draft. William Roberts
helped with much-needed laser printer advice.
APPENDIX
Consider the problem of computing the tiles intersected by the line joining points p 0
and p l . Let d x = p1.x - p0.x and dy = p1.y - p0.y with d x > 0 and dy > 0. Let
t O and t l be the tiles corresponding to p 0 and p l and ti = (ti.x,ti.y) be the tile at the
ith step. Y ( a )denotes the intersection of the line (p0,pl) with the vertical line x = a.
Then,
Y ( a )=po.y
+ dY
- (a - p O . x )
dx
Let a = W(ti.x + l ) , where W is the width of each tile. Then, if H is the height of
the tiles:
ti+ =
if Y ( a )> H(t,. y + 1) then (ti.x,ti.y + I )
else if Y(a)= H(ti.y + 1) then ( t,.x + I , ti.y
else if Y ( a )< H(t,.y 1) then (t,.x + 1, t,.y)
+
+ 2)
+
This can be seen from Figure 3. Let ei = Y ( a ) - H(ti.y
1). Then the resulting ti
depends on whether e, is positive, zero or negative. In the first case the y component
of t is incremented; in the second case both x and y are incremented and in the last
case only x is incremented. Now
ei = p0.y
dY (W(t;.x+ 1) - p 0 . x ) - H(ti.y + 1)
+ dx
-
Since dx > 0, multiply e, throughout by d x to obtainf; and the inequalities in the
algorithm are preserved.
f2 = dx X p0.y + dy(W(t,.x + 1) - ~ O . X ) - dx X H(t,.y + 1)
Consider now J - 1,
1 - 1
= dx
Xp0.y
+ dy(W(t,-i.x + 1) - ~ O . X ) - dx X H(t,-l.y + 1)
By subtraction,
f2 = J - 1 + Wdy(t,.x - t , - l . x ) - Hdx(t,.y - t,-l.y)
The value off2 gives a method for determining L , + ~ from t,. Therefore,f2-, determines
t, from t,-l. Hence,
iff,-l > 0 thenf, = f2--l - Hdx
if f2.-l = 0 then f2 = Wdy - Hdx
if f;.-l < 0 then f2. = fi-l + Wdy
SEGMENTS ON BIT-MAPPED GRAPHICS DISPLAYS
979
It remains to determine the initial value, fo:
fo = dx X p..y
+ dy(W(t0.x + 1) - P O X )
- Hdx(t0.y
+ 1)
which can be rewritten as
fo = dx(p0.y - Ht0.y)
+ dy(Wt0.x -POX + W) - Hdx
However, t0.x = p 0 . x DIV W and t0.y = p0.y DIV H . Therefore,
fo
= dx(p0.y
MOD H ) - dy(p0.x MOD W)
- Hdx
+ Wdy
A similar result for the case dy < 0 can be derived easily, and the cases d x = 0 and
dy = 0 can be dealt with separately.
The algorithm for generating the tiles intersecting the line (p0,pl) can therefore be
written as
function TileslnLine(p0,pl) =
begin
t0.x : = p0.x DIV W;
t0.y := p0.y DIV H;
t l .x : = p l .x DIV W;
t1.y := p1.y DIV ti;
TileSet : = {to};
t : = to
f := dx*(pO.y MOD H) - dy"(p0.x MOD W) - H*dx
+ W*dy;
do t.x # t l .x and t.y # t l .y +
if f > 0 + t.y : = t.y + 1;
f : = f - H*dx
0f
=
+
0 + t.x, t.y : = t.x
1, t.y
f : = W*dy - H*dx
+
1;
+ 1;
+ W*dy
0 f < 0 + t.x := t.x
f := f
fi;
TileSet := TileSet U {t}
od;
return (Tileset)
end
In the above function-definition {} are used to denote sets-{t} is the set with single
U is the set union operator. Note that the iteration ends with either
element t-and
t.x = t1.x or t.y = t1.y. This allows the simpler cases to be dealt with subsequently,
and also avoids the complication of testing for the situation where the end-point of a
line falls exactly on the vertical boundary of a tile.
REFERENCES
1. GINO-F User Manual, CAD Centre, Cambridge, U . K . , 1979.
2. 'Core graphics system: status report of the Graphics Standard Committee', Computer Graphics, 13,
August (1979).
980
M . SLATER
3 . GKS Infomation Processing Systems, Computer Graphics, Graphical Kernel System (GKS) Functional
Description, international Standard IS0 7942, 1985.
4. F. R. Hopgood, D. A. Duce, J. R. Gallop and D . C. Sutcliff, Intmduction to the Graphical Kernel
System (CKS), Academic Press, 1983.
5. A. Goldberg and D . Robson, Smalltalk-80: The Language and Its Implementation, Addison-Wesley,
1983.
6. R. Pike, ‘Graphics in overlapping bitmap layers’, ACM Transactions on Graphics, 2 , (2), 135-160
(1983).
7. S. Cook, ‘Playing cards on the Perq: an algorithm for overlapping rectangles’, Software-Practice
and Experience, 13, 1043-1053 (1983).
8. B. Bramer and D. C. Sutcliffe, ‘Application of Gino-F to use display file techniques on raster scan
displays’, in J. L. Encarnacao (ed.), Eurographics 81 Proceedings, 1981.
9. J. Warner and N. Keifhaber, ‘The DIGRAF implementation of the proposed G S P C standard’,
Eurographics 79, Bologna Italy, 1979.
10. J. D . Foley and A. Van Dam, Fundamentals of Interactive Computer Graphics, Addison-Wesley,
1982.
1 1 . J. E. Bresenham, ‘Algorithm for computer control of a digital plotter’, IBM Syst. J., 4, ( l ) , 25-30
(1965).
12. D. Pountain, ‘Realising a dream’, BY’l’E, 379-382 (1985).
13. Leslie M. Goldschlager, ‘Short algorithms for space-filling curves’, Software-Practice and Experience, 11, 99-100 (1981).
14. W. Newman and R. F. Sproull, Pn’nciples ofhteractive Computer Graphics, 2nd edn, McGraw-Hill,
1979.