The 2 Graphics Toolbox
This chapter discusses 3 philosophy and approach for designing graphics and graphic software systems. Our main assumption is that a person engaged in producing or using computer Systems that generate graphical displays will benefit in the long run by building a library of graphic routines (tools) that can be used over and over again. A second assumption is that by following a few simple design and development guidelines. the utility of these tools can be greatly enhanced. The guidelines are intended to help the graphics programmer or user develop displays in a structured. efficient and effective manner. The following discussion presents a framework that attempts to characterize graphics software. This characterization is used as a basis for the software guidelines detailed in later sections. These guidelines are intended to aid in the selection and development of graphics software. Very seldom will an off-the-shelf' graphics software package fulfill all of the needs of the user. so the graphics designer must enhance and augment the software supplied by a vendor in order to meet the needs of specific applications.
2.1 GRAPHICS SOFTWARE
Software for graphics is usually implemented as new commands or subprograms within some standard high level language such as Pascal. FORTRAN. BASIC or C. This makes available to the graphics designer all of the capabilities and features of the host language as well as the graphics functions. Data manipulation. calculation. file handling and other tasks can be performed in the host language and their results passed directly to the graphics routines. In addition. existing and future application programs written in the host language can be easily modified to utilize the graphics routines to produce a variety of graphical displays. Graphics software can be viewed as existing at three levels: primitive. operational and applications. Figure 2.1 portrays the scope and relationship of these three levels or layers. Software at the highest level (applications) is constructed from the software routines (tools) developed at the lower levels. For a given graphics device or system. the levels are separate and distinct. However. across different classes of devices the levels overlap and their distinctions become fuzzy.
Figure 2.1 Graphics Software
Primitive level software contains the minimum set of functions we need to create a graphics system. The basic function of primitive level software routines is to interface with the graphics display device and host operating system that is being used. Specific operating system functions that we will be interested in for graphical systems are: initialization and termination of graphics sessions. input(output, communications and file handling. Graphical display devices have a fixed and limited set of functions which they can perform. These might include filling a displayed object. producing a display point. drawing a straight line between two points and erasing all or part of a display. The primitives are highly device dependent and are usually provided by the graphics device manufacturer. Their form and structure are determined by the nature and capabilities of the graphics device. Software modules that interface directly with and control specific graphics devices are called device drivers. Operational level routines help us create and manipulate more complex objects. Many of the operational level routines are constructed from calls to primitive routines or other operational routines. For example the routine to draw a SQUARE could be written by appropriately calling the primitive routine named LINE four times. Similarly an operational routine. TARGET, could be written by calling the operational routine CIRCLE. Other operational routines could manage and transform our image representation (i.e. SCALE, ROTATE and MOVE). Once again these routines can be combined with other operational level routines and/or primitive routines to produce more complex objects and scenes. The level at which the final graphics presentation is produced is the applications level. Application routines or programs are produced from calls to other application level routines. operational and/or primitive level routines. An application routine BARCHART can be written from routines called RECTANGLE. SYMBOL (operational). LINE and MOVE (primitive). At the highest level. applications programs perform business or organizational functions that require the graphical display of data or images. Graphics functionality can be obtained in a number of ways. Some languages or dialects of languages. like the ones produced for personal computers. are supersets of standard languages and have graphics capabilities added to the base language. Generally these capabilities are not very sophisticated and provide primitive and limited operational functionality. Many of the commercial graphics packages are implemented as libraries of subroutine calls accessible from a number of host languages. These packages provide a set of routines at the primitive level and many more routines at the operational and applications level. Another means for providing graphics capabilities is through "driver languages" such as Adobe's PostScript. Display devices such as printers and monitors that employ PostScript have micro-processors that interpret PostScript commands. PostScript can be viewed as a sort of graphical language with a broad set of primitive and functional level commands. PostScript has commands for drawing (lines, circles, etc.) as well as commands for performing graphical operations such as scaling and rotation. Users can write programs in a host language that pass commands and data to PostScript for it to execute. The toolbox concept is borrowed from other skill oriented professions such as carpentry. plumbing and even the medical profession. The purpose of the toolbox is to support a specific domain of work. A toolbox for a graphics user in a particular domain would provide some general. "all-purpose" graphics objects and functions as well as a set of domain specific graphics objects and functions. A carpenter's toolbox might contain a saw for general wood cutting, but might also contain a circular saw for specific applications. In the same manner, a graphics toolbox for a golf course designer would include a collection
of regular geometric figures such as circles, rectangles, triangles. etc. as well as a set of application specific objects such as tees, flags, trees. Sand traps, etc. The toolbox would include a set of common generic operational functions that would permit scaling, translation. rotation. projection and other graphical transformations and a set of specific functions (e.g. dogleg, hill. etc.) that would permit shaping and positioning greens. fairways and other application specific objects. The ability to select an object such as a fairway and shape it as a dogleg right or left is fundamental to the application of designing a golf course. The basic purpose of application specific toolboxes is to make graphics systems more intelligible to the end user and to make them easier to use than many graphics Systems currently are. The basic goal of an application specific set of graphical tools is to reduce the need for the end user to learn and operate in the domain of the graphical primitives and permit him or her to concentrate on the graphic design task and minimize his or her need to deal with programming. In other words. the graphics toolbox allows the graphics designer to work with high level objects and functions that are in the designers domain rather than forcing the designer to work at a low level in the primitive graphics domain. The graphics programmer needs a similar toolbox in order to build the application specific graphics system for the end user. The programmer's toolbox contains a different set of tools but they are intended to serve a similar purpose to the end user's toolbox.
2.2 GUIDELINES
The next few sections focus on defining and constructing graphics toolboxes for specific applications. The suggestions provided are intended to stimulate the reader into thinking about graphical problems using the toolbox approach. They are not presented in a particular order since we view the construction of a graphics toolbox as an iterative and wholistic process.
Representation
For a given figure or set of figures there exist several ways in which the figures can be represented. Some representations are easier to manipulate than others. Some make interaction with the user more straightforward. Others conform to a standard representation scheme for a technical discipline or vendor's software system. For example, a square or any polygon can be represented by the coordinates of the points which are its vertices (actually only n-I coordinates are needed for certain figures). See Figure 2.2a. For a square. knowing the coordinates of two diagonally opposite vertices will do (Figure 2.2b). Specifying two adjacent vertices of a specific side is also sufficient (Figure 2.). Finally, as in Figure 2.2d, stating the coordinates of a vertex, the length of an adjacent side and the orientation of that side with respect to some reference fully defines a square. All of these representations are equivalent in their ability to describe a square. However, these representations are not equally generalizeable. For example. the representations in Figure 2.2a and 2.2b work equally well for any rectangle, while the other two representations are not sufficient to describe a rectangle. In addition, the representation of Figure 2. will describe any four-sided figure while the second representation is limited to rectangles. Specific methods of representation are covered in Chapter 7, but nearly all graphic devices
utilize the concept of a display area that is a rectangular grid similar to a sheet of graph paper. Each point on the grid has an X and Y address called a coordinate. These addresses begin at zero or some reference point and extend in increments to the maximum permitted by the display device. Figure 2.2 Alternative Representations for Specifying a Square
Many disciplines use graphical symbols. icons or objects to convey information in presentations. These symbols are used independently or combined to analyze. design, simulate or represent an application are Graphical representations are commonly used in architecture. science. engineering, business, the social sciences and the humanities. Figure 2.3 shows several example symbols from the computer scientist's technique of flowcharting and some of the symbols used by a railroad designer. Representations ought to be selected to facilitate some aspect of the application, whether it be programming the application or making the user interface clearer and more effective. Try to select a single representation scheme that can be used uniformly throughout the application. Select a representation that is capable of representing more than one type of graphical object Use a representation that is natural for the particular domain of the application. Avoid using multiple representations or changing representations within a single application. if possible.
Figure 2.3 Graphical Symbols from Two Domains
Modularity
An important general guideline is that all graphics software should be concisely packaged. Graphics routines should be small (no more than say 50 lines of code or one page and should perform a single function. Modules should be given names that clearly reflect the function that they perform. Routines performing complex functions are built from routines that do simple things. Routines should have minimal numbers of entry and exit points. The normal software module construct of the host language (je. functions. subroutines. procedures. etc.) ought to be used as a mechanism for graphics routine generation. This makes other host language functionalities easily accessible to graphics generating programs. There is often a tradeoff between producing a small number of large routines and creating a large number of small routines that achieve the desired functionality. The latter usually produces (he more usable. portable and easier to maintain system.
Generality
A third guideline is to write the graphics routines to be as general as possible. Thus. there will be fewer routines in your graphics library to write and maintain and fewer changes will be required in reusing the routines in new programs. Writing a rectangle (RECTANGLE) routine is preferable to writing a SQUARE routine and a polygon (POLYGON) routine is preferable to either of them. Since SQUAREs and RECTANGLEs are figures that we regularly use. we can simply write routines for them that consist of calls to the POLYGON routine. See Algorithm 2.1 for a Visual Basic language implementation of this. Note that we have ignored some
performance issues at this point. While a square routine written directly will in general be faster and consume less storage than the square routine written from the polygon routine. the latter is easier to write. Since most of our concern here. is programming speed and efficiency. we prefer to start with the easiest to implement version of a routine. If performance becomes an issue. then the SQUARE routine can be replaced with a more efficient version or even the corresponding inline code. Algorithm 2.1 POLYGON and SQUARE Routines in Visual Basic
Public Sub Polygon(x() As Double, y() As Double, n As Long, color As Long) Dim i As Long PSet (x(0), y(0)), color For i = 1 To n - 1 Line -(x(i), y(i)), color Next i Line -(x(0), y(0)), color End Sub Public Sub square(x() As Double, y() As Double) Call Polygon(x, y, 4) End Sub
An example of the data required for the above routines for a typical 50 unit square shown in Figure 2.4 is given below. The values that must exist in the X and Y arrays for the POLYGON and SQUARE routines to work properly are: X(1) =100 X(2) =150 X(3) =150 X(4) =100 Y(1) = 50 Y(2) = 50 Y(3) = 100 Y(4) = 100
The value of n would be 4 for the above set of X and Y coordinates.
Figure 2.4 Using the SQUARE and POLYGON Routines
Documentation
As you have probably already noticed. we believe the routines should be thoroughly self documenting. Each routine should carry a header describing the function of the routine and the variables that it receives and returns. Comments should also appear throughout the routine. Finally. the routine itself and all variables that the routine uses should. if possible. be given names that reflect their purpose. We have found this kind of documentation extremely valuable in writing and debugging graphical software. Since you will be writing as few routines as possible to put in your toolbox and reusing them as often as possible. the documentation overhead is minimized.
Independence
By their nature the primitive routines are highly device dependent and the application level routines are application dependent. These dependencies cannot be avoided but must be minimized to produce a graphics system with a high degree of flexibility and portability. This is done in several ways. First, the device dependent routines should be localized and placed at the lowest software level possible. Ideally device dependence should remain at the primitive level. Operational level routines will then be unaffected if the primitive level routines they call are modified or the graphics program is moved to a different display device. This also requires that the calling sequences. representations and variable definitions be standardized For example, operational level routines such as POLYGON will remain unchanged if the display device is changed from a bit mapped CRT to a pen plotter. Only the MOVE and LINE drawing routines need to be modified or replaced.
Algorithm 2.2 Sample LINE Routines 1.) void lineto (float x, float y) 1* lineto - draws a line 1 1* input: x x coordinate of the line endpoint y = y coordinate of the line endpoint output: return: *1 plot (x,y,2); 1* CALCOMP routine calls to draw a line *1 penup; 10 Computer Graphics: A Tool Baseci Approach 2.) void lineto (float x. float y) / lineto - draws a line 1* input:
*1 x = x coordinate of the line endpoint y = y coordinate of the line endpoint output: return: draw (x.y); /* Plot- 10 routine call to draw a line */ At the applications level, steps can be taken to identify which portions of an application might be common to a number of other applications. These can be put into separate routines for use by all of the particular applications. For example. many applications may use a bar chart in one form or another. If the BARCHART routine were written with fixed parameters (size, bar orientation. coloring, labeling, etc.). there is a low probability that this routine would satisfy the requirements for each of the potential users. A BARCHART routine with variable parameters or a set of routines each of which produce a portion of a bar chart would have a wider range of applicability. It is also important to create these routines in a consistent manner with similar parameters and similar functions.
Analysis
It is always a good idea to analyze from a number of perspectives the graphical problem before proceeding to specify software for development. Often there are multiple approaches to producing a graphical display hat have dramatically different consequences for software design. Consider the case of the simple pie charts shown in Figure 2.5.
Figure 2.5 Pie Charts
If we were to conceptualize the general problem of producing pie charts as in 2.5 we would write our PIECHART routine as calls to the CIRCLE and LINE routines. This would not allow us to use the same software to create the pie chart of Figure 2.5b. If. however. PIECHART were designed to draw a portion of a pie and implement it as calls to ARC and LINE routines. the graphic of 2.5b could be created (by two calls to the new PIECHART routine) as well as the graphic of Figure 2.5a and many other pie chart variations. Alternatively we could have defined SLICE as a call to ARC and two calls to LINE and once again have the capability to produce both displays. In many application domains (i.e. drafting, scientific disciplines. engineering, architecture, music. etc.) there are numerous standard graphical symbols and structures that are used repeatedly. These should be part of the application specific toolbox.
Efficiency
The guidelines stated here have as their main objective to improve the efficiency of the graphics programmer. The time and effort required in going from problem statement to graphical display will be greatly reduced by adhering to these guidelines. This does not necessarily that mean the graphics hardware will create the graphics display efficiently. When the graphical display problem is of a one-shot. ad hoc nature. efficiency is not an issue. But. when many displays must be created especially on a slow device such as a pen plotter. efficiency becomes important. Efficiency is typically achieved by selecting or developing algorithms that minimize the consumption of computing resources. Computing resources are typically time and space related. For instance. algorithms that are incremental in nature and only require addition and subtraction or integer arithmetic are preferred over those that require floating point operations. Trigonometric functions should be used only when absolutely necessary as they are notorious for their computational inefficiency. In a graphical application system, not all of the resources are available in the same amount
nor are they consumed at the same rate. It is the responsibility of the graphics programmer to manage the use of his or her resources. The graphics programmer is generally concerned with overall efficiency. Sometimes the inefficient use of an abundant resource conserves a scarce system resource.
Data Structures and Data Manipulation
Modeling a graphic object or an entire graphics scene requires data structures that preserve the relationships among the components of an object or a scene. An object may be composed of several subjects. While transforming the object. it may be desirable to transform the sub-objects and maintain the relationships among the sub-objects. For example, we may construct an image of a carousel with a number of animals on it. Each animal is at a fixed location with respect to the carousel and each other. As the carousel turns, the animals move, not with respect to each other or the carousel, but with respect to the environment. As another example, consider a drawing of a house in a CAD system. The house has doors, windows, walls, roofs, etc. It may be necessary to move the entire image to a different location on the display. Alternatively, we may wish to make a particular window larger. It is thus desirable to be able to reference and manipulate the house as an entity as well as having the capability to reference and manipulate each of the sub-components. Processing the graphical components of an object or image and their relationships requires software routines that can perform the necessary processing for traversing the data structures. It is therefore necessary to provide tools (routines) for performing the necessary data manipulation functions. These software tools should provide the capability to create, delete, modify, relate, expand, transform or display complex objects. Hierarchical, tabular or other kinds of structures can be used to represent the relationships among components of an object. For example, a bicycle can be conceptualized as composed of a frame, handle bars, seat, wheels, pedals and a chain as shown in Figure 2.6. Figure 2.6 Bicycle Hierarchy
In this tree structure, the root is bicycle and the branches are frame, seat, etc. Each of the
branches may be broken down into further branches. For example, Figure 2.6 shows the wheel branch broken into hub, bearings, spokes, rim, tire and tube sub-branches. These and any of the other branches, in turn, may be further broken down as needed. The bicycle and each if its subparts can be considered to be a node in the hierarchical structure. The relationship between nodes at each level in the hierarchy can be considered to be a parent-child relationship. At each node there would be an identification of an object or component. a pointer to a structure representing the component for purposes of displaying it and a pointer to a list of child nodes. The matrix at each node provides positioning information and data used for drawing the components on the display surface. The data structure might be represented as a link list as shown in Figure 2.7. In this structure, child pointers point to components at the next level in the hierarchy and next node pointers point to the next component on the same level. In our bicycle example, the root node (1,icycle) would point to frame as a child and frame would point to seat as a next node on the same level which means it is also a child of bicycle. If frame had a child node, then the child pointer in the frame node would point to it. If a node has no children, its child pointer would be set to a null value or would point to itself. The wheel node is also a child of the bicycle node. It would be pointed to by the next pointer of the handle bars node. The wheel's next pointer would point to the pedals node. Wheel's child pointer would point to the hub node. The nodes on the same level are called siblings. Thus. the next node pointer is also called a twin pointer. Figure 2.7 Linked List Representation
In order to implement data structures such as this. it is necessary to write software modules that provide the required functionality in a graphics application. As part of a toolbox for graphics, a
set of modules is required to handle such data structures as shown above. This it might contain modules such as: Allocate Create-root Add-child-node Add-sibling-node Get-node Get-next-child-node Put-child-node Allocates memory for the data structure Creates a root node for a structure with a specified ID Adds a new child node to the specified component. Adds a new sibling node to the specified component. Gets the specified node by its component ID. Get the next child node by following the child pointers. Replaces the current child node with the ID and matrix data specified. Put-sibling-node Insert-child-node Insert-sibling-node Delete-node Replaces the current sibling node with the ID and matrix data specified. Insert a new child node after the specified node with the ID and matrix data provided. Insert a sibling node after the specified node with the ID and matrix provided. Delete the specified node.
These toolbox routines represent the operational level modules required. At the application level we might have a routine such as: TRAVERSE-TREE (NODE_ID POSITION, STATUS) This routine would call three lower level routines: GET-NODE (ID). GETNEXT CIIILD and GET-NEXT SIBLING. The order of traversal may be fixed such that all child nodes from the current node are retrieved before sibling nodes. This would provide a top to bottom, left to right order of tree traversal starting with the specified node ID. If the specified node ID was the root node, then the entire tree would be traversed. As a structure (tree) is traversed, it is drawn on the display surface by using the representation and positioning information in the matrices at each node. If each node's component is represented positionally relative to the root node, then we must supply information about the position of the root node on the display surface. This information is contained in the argument "Position". The representation contained in the matrices at each node may be simple line representations such as endpoints or endpoints and displacements, vertices of a polygon, center and radius of a circle, three points of an arc, ASCII text codes, bit maps of objects, etc. In addition, the object representation may require one or more transformations to perform translation, scaling, etc. in order to generate the coordinates necessary for display purposes. The different forms of representation are discussed throughout the remainder of this look.
Since the world coordinate data representing the objects and components of objects is usually stored on a direct access device, such as a floppy or hard disk, it is usually necessary to have a set of software modules that perform input and output to these data files and in many cases perform conversions, edits or translations where necessary. These routines (modules) will become a part of the graphics toolbox as well. It is important to isolate all device dependent program statements into separate modules and not permit these to be scattered throughout toolbox modules. This permits changing the program statements in only a few modules when the package must be ported to new a hardware platform. Thus, all file opens, reads and writes to hardware devices will be relegated to subroutines, procedures or function calls. In addition, all access method related routines for file VO must also be isolated. The access method determines how and where the next data record will be retrieved or stored on the storage medium. The access method may be sequential, direct or indexed. There ire many techniques of computing direct or indexed access methods. The software modules for these must be localized in a set of routines that are called from higher level routines. Thus, a hierarchy of file access routines might appear as shown in Figure 2.8. Figure 2.8 File Access Routine Hierarchy
The blocks labeled read_dir, write_dir, read_index and write_index are composed of modules that determine the record location to read or write. This may include a hashing algorithm or Btree access and update routines which may be written by the graphics software developer or may be called from a library of routines supplied by the vendor of the operating system. It is important to view the entire graphics system as a toolbox of software modules that can be called to support various graphics applications. This provides the versatility and flexibility required of a graphics package.
2.4 A CASE STUDY - THE LOGIC DESIGNER
To illustrate many of the principles that we have advocated in this chapter we will present a graphical system design case study. The graphical system we have selected as our example is a system to aid a computer logic designer. While a professional version of such a system would require a book to describe in itself. We will merely outline the design and main features of the system and detail how a few of the system features would be implemented. A logic designer creates devices, subsystems and systems that are used in computers and other electronic systems. The designer works with logical (AND. OR. NOT etc.) and other functions to create a device that performs some function such as converting a binary representation to a decimal representation. Electrical circuits exist to perform each of these elementary logical functions (AND. OR. etc.). These elementary circuits are combined to create larger circuits that perform more complex functions. The logic designer typically works using some graphical displays to help in the design of a circuit and to communicate a finalized design. He or she uses standard graphical representations (in this case MIL STD.) for the logical functions. A few example standard circuit graphical representations are shown in Figure 2.9 below. Figure 2.9 Standard Graphical Representations for Logic Circuits
Several of the more common standard circuits are shown above. There are many more types of circuits - too numerous to display here. As one can see. Some circuits are combinations of others. For example. the NAND is a NOT AND. an AND followed by a NOT. New and more complex circuit designs are made by appropriately connecting the standard circuits. D...