computer graphics interface and cad applications

Computer Graphics Interface and CAD applications David Arnold

This paper sets out to show the relevance of the proposed Computer Graphics Interface Standard (DP 9639) to typical users and implementors of CAD systems. The paper first considers the architectural relationship between the CAD system and CGI devices, and the potential benefits associated with a CAD system which incorporates such devices. The major features of the CGI are then reviewed briefly and contrasted with the functionality of GK5 and the paper concludes by considering some probable future directions for standards in this area and some consequences of the moves.

computer graphics, graphics standards, CGI

The proposed Computer Graphics Interface standard 1 is being developed to provide a standard range of facilities to be used in communicating to graphics devices. It is a complex evolving multipart standard intended to provide functionality useful to knowledgeable builders of graphics systems. This paper seeks to show the implications of the CGI for both implementors and users of CAD systems, and to introduce the range of functionality provided. The reader is assumed to be familiar with the major concepts in GKS 2 and the paper highlights the areas in which the CGI currently differs in function or philosophy from GKS.

U N D E R L Y I N G A R C H I T E C T U R A L M O D E L S

To quote from Bono3,'architecture is central to understanding the purpose of a standard' and this section therefore uses architectural models to introduce the description of the area of application of the CGI standard.

The first stages of standardizing computer graphics systems were undertaken when time-shared host/terminal configurations were the norm (see Figure 1), with most being based on random scan vector drawing displays. By the time the CG1 becomes a standard, powerful, multiple raster display, windowed workstations connected to each other and to servers across high speed networks wilt be the norm (see Figure 2). However, despite this drama- tic hardware transition, the same constituent parts of the graphics system can still be identified (see Figure 3) although the proportion of the processing performed on dedicated hardware has changed dramatically.

Figure 3 shows that for any architectural configuration there are essentially at least four components present: the application's code, the device independent part of the graphics system, the device dependent part and some device control. Within this model two likely candidates

School of Information Systems, University of East Anglia, Norwich NR4 7TJ, UK

for standardization can immediately be identified:

• the applications package/graphics system front end interface (API)

• the device independent/device dependent (DI/DD) interface within the graphics system

Following on from Seillac 14, standardization efforts turned first to the API, producing the early versions of GKS in parallel to the Core s definition. These have developed since into the International Organization for Standardization (ISO) standard GKS and the PHIGS 6 proposals, nearing completion. Attempts at standardizing the DI/DD interface were only begun when GKS was suf- ficiently stable, and lead to the metafile standard (CGM 7) and the CGI work described here.

The relationship between CAD systems and the CGI therefore depends on the nature of the CAD system and its graphical support. In particular, where the CAD system is built on top of a graphics package supplied by another manufacturer, then the arrangement in Figure 3 would map on to the arrangement in Figure 4. The benefits in this case would depend on the degree to which the graphics package supplier was exploiting standard techniques,

:1 Time shared

host

i Grao,,.. I terminal

-~ ~ Other = ~ users

Shared

Dedicated (limited local processing)

Figure I. Typical CAD-graphics hardware configuration c. t975

<3

'Number t cruncher'

I I I

Microfilm service

I 1 1 Other workstation:

E>

Workstation

Figure 2. Typica/ CAD-graphics hardware configuration c. 1987

444 0010--4485/87/080444--07 $03.00 (~) 1987 Butterworth & Co (Publishers) Ltd computer-aided design

Application Application Dedicated workstation

Graphics Graphics applications code front end front end

Device independent Graphics Graphics front end back end back end

Device dependent Operating Oedicated back end

system device control j Device/window

manager

Terminal hardware C. 1987 and software

c. 1975

Figure 3. Underlying components of the architecture in Figures I a n d 2

Network connection

E.g. GKS from another manufacturer

CAD database ]

The Computer Graphics Interface

Figure 4. Relationship between CGI devices and the CAD system

and, assuming this was being done, the advantgages of portability to new devices, and in operating over ranges of different hardware configurations, should be apparent.

A more interesting situation arises where the CAD system has graphics built in, even though this is probably via a very similar interface to the previous situation. Here, the implementation of the graphics system could be tuned to take more direct advantage of the facilities provided by CGI devices, which would allow the CAD system designer to move the load of graphics updating much closer to the eventual display, while continuing to maintain well-defined, standard operations. If it is assumed that the CAD system is implemented using a sensible layered configuration, the distinction between these two is drawn in a somewhat artificial manner. As in both cases it is effectively the implementation of the graphics system, as opposed to the application specific code, that starts to benefit from improved efficiency. This observation is a natural consequence of the intended place for the CGI in the 'family of graphics standards'. It is a graphics system implementor's tool kit incorporating facilities intended for knowledgeable system builders and not intended to provide, for example, the level of protection required in error handling for potentially naive users of the application. Figure 5 shows the relationship between the CGI and the API standards, with the second case corresponding to the 'box' labelled 'other' systems at the bottom of the pic- tures. The figure is based on Figure I .I of DP9636, and is inadequate in a number of respects. It does not show, for example, the need to convert both GKS-3D and PHIGS commands to 2D elements before passing through the CGI (with the current version).

FACILITIES IN THE CGI The CGI is a multipart proposal with six parts to the functional description. Part 1 of the proposal is an overview and includes no functionality but introduces the other parts as follows:

• Part 2 - control, negotiation and errors • Part 3 - output and attributes • Part 4 - segmentation

• Part 5 - input • Part 6 - raster

These parts define the abstract functionality for the interface and, in common with other graphics standards, this functionality then has to be realised in specific languages and/or encodings. The proposals for language binding and data encoding standards are also introduced in Part I, and are the subject of proposals for associated multipart standards. Since the project is at the stage of draft proposed International Standard and has not yet been accepted for progress to Draft International Standard, it is still subject to change but no new areas of major functionality should be added.

The functional specification defines how a particular facility should work, if required at the interface. Whether the features appear in any implementation will depend upon the constituency profile to which the implementation claims to conform (see section 3.6). For example, vector devices would be likely to be driven via a CGI profile which omitted all the raster functionality (see the section on stored graphic objects).

Control, negotiation and error handling The control facilities include those functions concerned with device management and coordinate space specification. Device control allows intialization and termina- tion of a CGI session, setting the device to known default

Workstation

Application Language Functional Workstation programs bindings standards software

11

s - - - t 1

J; ' ' I

H t I

I

: _------El

-I

Devices and rnetafiles

CGI interface

Figure 5. Computer graphics standards interrelationships

volume 19 number 8 october 1987 445

Marker

Line functions

Marker function Text functions

Filled-area functions

Image functions

Generalized drawing function

Polyline Disjoint polyline Circular arc 3 point Circular arc centre Circular arc centre backwards Elliptical arc Polymarker Text Append text Restricted text Polygon Polygon set Rectangle Circle Circular arc 3 point close Circular arc centre close Elliptical arc close Cell array Pixel array (described in Raster part) GDP

states, control of the state of the display surface etc. Also included are deferral mode control functions similar to those in GKS, etc.

Coordinates and other dimensions in the CGI are, with a few exceptions, defined in virtual device cordinates (VDC). The exceptions relate to those aspects that control aspects directly in the physical units of the device or device coordinates (DC). The VDC space is mapped onto the display surface using a window to viewport mapping which can be specified using native device units, scaled metric units, or percentage of display area. Each of these methods maps to specific applications with scaled metric units likely to be particularly useful to CAD systems, giv- ing, as it does, actual sizes of end result. A percentage of display area is used for subdividing the display space without prior knowledge of the actual size or resolution of the device. Functions to control clipping are also included in Part 2.

The CGI approaches error handling in a markedly different way from GKS. It begins from the philosophical standpoint that the system builder using the CGI is expected to know what he or she is doing. Hence the overhead and enforced error reporting can be avoided by allowing less serious errors to be handled without interaction with the generator of the CGI command stream. Errors are categorized by degree of seriousness, with control of each category to allow error reporting and detection to be switched off. Thus full detection and reporting may be used during system development, but disabled when the system goes live to improve perfor- mance.

Output and attributes The output primitives provided in the CGI are very similar to those in the CGM, which in turn are closely based on the GKS philosophy. Individual primitives in GKS (polyline, polymarker, cell array, text and filled area) have

Table 2. CGI rendering attributes

Primitive class Individual only Bundled attributes attributes

Line Line type Line width Line colour Marker type Marker size Marker colour Text font index Text precision Character

expansion factor Character spacing Textcolour

E

Text attributes

Fill attributes

Character height Character orientation Text path

Text align ment Character set index Alternative character

set index Edge visibility Fill reference point Pattern size

Interior style Fill colour Hatch index Pattern index Fill bitmap Edge style Edge width Edge colour

Begin Figure Polyline(A,B) Elliptical Arc(B,C) Polyline(C,E) Circular Arc Backwards(E,F) Polyline(F,G) Circular Arc(G,H) Polyline(H,I) 3 x {Circ Arc( ....... ),

Polyline( ....... )} Circ Arc(O,A) End Figure

Table 1. CGI output primitives

Primitive c lass Primitives

Figure 6. Example of the construction of a closed figure

become classes of primitive in the CGI. This has the effect of increasing the number of primitives without expanding the number of bundle tables. The only new bundle table that has been added is the edge bundle table used with filled areas. The list, while longer than that in GKS, is virtu- ally identical to that in the CGM (IS8632) with the addition of 'Circular arc centre backwards' (see Table 1 ).

Attributes are handled either bundled or individually with some, which are felt to be defining essential characteristics of the picture, only available individually. Again, these follow a very similar format to GKS, with Aspect Source Flags (ASFs) associated with every attribute which is available both bundled and individually, and an index to the appropriate bundle table used whenever bundled values are chosen. Table 2 lists the attributes by primitive class to which they apply.

446 computer-aided design

l lndividual I I Bundled 1 attributes attributes

Figure 7. Stored objects in the CGI pipeline

Open Sug t Set LW1 Polyline 1 SeILW2 Polyline 2 Close Seg

Individual [~ - -X -~ attributes ~

J, f J, U.. Pu I ~ ~,,'--PL2

Segment \ / ~-tore

Open Seg 2 Set LW3 Polyline 3 Copy Seg 1 Polylme 4 Close Seg

Individual [ - ~ - ' ~ attt'ibutes ~

Inheritance ~ \ PiSLW3 / ,,,.r f \

\ ~ Segment store

Open Seg 2 Set LW3 Polyline 3 Copy Seg 1 Polyline 4 Close Seg

Ir:bdividual ~

PL3 ~ P L I I C ) ~PL2(C) ~ P L 4

ln.~,it~o~'--~-' \ ;~'~ / filter "~ \ PI.2 LW ;~ /

\ ~ Segment s t o r e

Figure 8 (a) Definition of a simple CGI segment, (b) segment copy without inheritance and (c) segment copy with attribute inheritance (notice that all lines inherit the same line width even when they were indistinguishable before the copy.

The closed figure facility, available only in the CGI, allows the client to construct a filled area using line class and filled area class primitives to define the boundary of a more complex shape. Such shapes can comprise several closed loops with the end result being rendered using the appropriate filled area attributes (Figure 6).

Stored graphic objects The CGI defines two types of stored graphics object- seg- ments and bitmaps (see Figure 7). Segmentation is a mechanism for the storage and manipulation of non- parametrized or partially parametrized descriptive defini- tions; bitmaps are used for the storage and manipulation of images or portions of images.

Segments Segmentation is a well understood concept in computer graphics, but its specification and realisation vary a great deal. The CGI segment model is similar to that in GKS. Segments can be transformed, made visible or invisible, highlighted, ordered front to back, and made detectable or undetectable. These properties are associated with the whole segment. For example, individual primitives can be highlighted only if they constitute the whole segment. Segment transformation and other segment attributes are applied when the segment is displayed. They provide a mechanism for altering the interpretation of the body of the segment, but do not affect its stored description.

Currently, CGI has only limited capabilities for altering segment content. No selective editing of segment elements is allowed. A segment can only be renamed, deleted, reopened to append elements, or copied into another segment. In copying, the source segment is read, its coordinate data is transformed through a copy transformation, and the resulting elements are inserted into the body of an opened segment. No hierarchical description is maintained; that is, no element is stored that refers one segment to another. The segment attributes of the copied segment are ignored during copying; those of the segment into which the copy is made are used at display time.

[3raphics primitives are stored in segments with the individual attributes, ASFs and bundle indices applicable at the time the segment was defined. When a segment is redrawn these attributes are used, along with the bundled attributes applicable at the time of (re)display. When one segment is copied into another the inheritance filter, see Figure 8, is used to determine whether the original attributes are also copied (see Figure 8(b)) or whether they are replaced by those in force at the time the copy takes place (inherited from the open segment- see Figure 8(c)). Primi- tives in the segment being copied, that had different values of attributes in that segment, will have the same value for those attributes that are inherited during the copy (Figure 8(c)). This effectively makes the inherited attribute a property of the segment, rather than of individual primitives.

Bitmaps Bitmaps provide a second point in the graphics pipeline at which a snapshot of the graphics output data can be stored and modified. They represent a second level of storage, much farther down the pipeline than segmentation, where all primitives have been rendered to pixel values.

The basic units of storage are bitmaps, which are rectangular arrangements of pixels. Two types of bitmaps are defined: full-depth and mapped. The pixels of a full- depth bitmap match the physical characteristics of the pixels on the device in use, in number of bits/pixel and physical dimension. A mapped bitmap has only one bit/ pixel.


I Outin service to application

oo,y \ oo,ou, oo,

~ Factory J. I Ill Figure 9. Coordinated use of separate output and input CGls

Bitmaps define target portions of image space in raster form. They are created by requesting a bitmap suitable for representing a particular portion of VDC space, according to the current mapping of VDC to physical device coordinates. This defines the position in DC and the number of pixels in x and y required to hold the contents of the region requested. Any subsequent change in the VDC-to-DC mapping will not affect the number of pixels involved in existing bitmaps, though it will affect the area they represent in VDC.

Once created, a bitmap can be selected as the destination for graphics output. This allows portions of a picture to be defined and named. These portions can then be combined using either two or three operand raster operations, which allow logical combinations of bitmap parts.

In an implementation supporting the raster functions of the virtual device, at least one full-depth bitmap is directly tied to the display mechanism. This is called the displayable bitmap, and it is affected by screen modifying operations in the same way as the display surface of any virtual device. If this bitmap is used as the destination for any raster moving operation, the displayed image is affected. The CGI supports multiple displayable bitmaps, allowing, therefore, direct control of double buffering, or multiple frame applications to be supported at device level.

The raster part also introduces two other concepts not found in GKS. The first is the 'pixel array' primitive which is like a cell array but with the restriction that no re- sampling is performed in rendering the pixels. They cor- respond 1:1 to the pixels of the display bitmap irrespec- tive of the DC system in use.

The second new concept is the 'bitmap fill attribute' which allows a fill area primitive to be filled with a repeated pattern taken from a region of bitmap.

Input CGI input functions are designed to support the input models of other standards, even where CGI may, in fact, be controlling only one aspect (workstation or device) of a system that combines several virtual devices. Thus the complete system may be capable of providing the full range of graphics interaction (for example, all input classes and local echo), while CGl-controlled components may perform only a subset of the actions (for example, a tablet with no locally associated display surface).

The classes of input supported are the six standardized in GKS and proposed for GKS-3D 8 and PHIGS: choice, locator, pick, string, stroke and valuator along with two new classes - Area (for support of flame grabbing, etc)

and General input class (equivalent to the generalized drawing primitive). Devices in these classes can be supported in one of four modes: request, sample and event (the three modes included in GKS), and echo request. This last is designed to allow support of echoed output on a device operating in parallel to one being controlled by a CGI input command sequence. This amounts to co- operation among separate instances of virtual devices and might, for example, include an output device echoing input from a loosely coupled tablet, as shown in Figure 9.

All CGI functions operate synchronously. Any asyn- chronous operation is supported through local independent processes responding synchronously to CGI commands.

A virtual input device of any class consists of a number of processes, the number and type of which depend on the mode of operation in which it is initialized. Any initialized logical device has an associated process whose function is to maintain a current value (the measure) of the associated physical device. For input classes with triggers (request, echo request and event), an event monitor is created to control the logical input device. For each trigger (and for the timeout mechanism in request and echo request), a second independent process is created to monitor the state of the trigger and notify the event monitor when the trigger fires. A similar process is also associated with the break mechanism, which the operator invokes to abandon an input operation. For echo request input, another process monitors the measure process and fires whenever the measure value changes.

The effect of the sample input function is to return the current value of the measure process and current validity status. No other processes are involved.

Implementing the standard DP 9636 defines the abstract functionality for the interface and, in common with other graphics standards, this functionality then has to be realised in specific languages and/or encodings. The proposals for language binding and data encoding standards are to define three associated multipart standards:

• A multipart standard for data encodings of Parts 2-6. Three parts will be defined: o Character encoding for minimum length of the

resulting encoded data stream. o Binary encoding for low computational overhead

of encoding and decoding. While one encoding of this type is envisaged in the standard, as with the CGM standard encodings, it is anticipated that there will be a requirement for manufacturers' private encodings of this type. The level of conformance certification that can be given to systems using such private encodings can only be 'functional' rather than 'full' (see below).

o Clear text encoding for us poor humans to cope with (i.e. for reasons of being readable, editable, long winded, etc. for debugging and other pur- poses).

• Multipart standard of language library bindings. Each part of this standard will define a library of procedures to implement the CGI interface in a particular prog- ramming language. The parts envisaged will be


Table 3. GKS Constituency profiles

Profile Workstation type GKS level

GKSb In b GKSc In c GKS 0 Out 0 GKS 1 Out 1,2 GKS 0b Outin 0b GKS 1 b Outin 1 b,2b GKS Oc Outin 0c GKS lc Outin lc,2c GKS bR In with Remote Echoing Input b GKS cR In with Remote Echoing Input c GKS OR Out with Echo Output 0 GKS 1R Out with Echo Output 1,2 GKS 0bR Outin with Echo Output 0b GKS lbR Outin with Echo Output lb,2b GKS0cR Outinwith EchoOutput 0c GKS lcR Outin with echo Output lc,2c

ordered as for the other language binding standards in the graphics area: o Fortran language binding o Pascal language binding o Ada language binding o C language binding

• Multipart standard of single entry point language bindings. The parts of this standard will bind the CGI functionality to each of the above languages in the form of a single entry point procedure. The same languages have been allowed for in the structure of the proposed new standard.

The structure of these three proposed multipart standards has only just been approved and work is still at the 'Initial Draft' stage. The first parts being worked on are the Binary encoding, and Fortran library binding, with other library bindings following shortly behind. Clearly, the CGI must be able to provide direct conve-

nient support for GKS in any of its many combinations of level and device class. In addition, the communication of graphics metafiles using the CGM must be easily mapped to CGI commands, and there are other user constituen- cies, which should be taken into account in the formula- tion of such a support standard.

Conformance and constituency profiles Part 1 also introduces the concepts used in defining conformance to the standard. Two levels of possible conformance are anticipated:

• Full conformance where the CGI functionality con- tained in a constituency profile is provided in the form specified by one of the language bindings or data stream encodings.

• Functional conformance where private encodings have been used, but the functions incorporated in the implementation perform according to the abstract functionality laid out in Parts 2-6 of the CGI.

With the range of graphics systems and devices to be interfaced there is a requirement to support a range of different interface configurations. For example, there is a requirement to be able to support output only devices

using either 2-way or 1-way communications (for example where spoolers only support 1 -way transfer of information). In addition input only and interactive devices must be supported and the optionality of coping with one half of an interaction sequence (eg. the input with remote echoing, or the echoing of inputs from another device) must be addressed. Even in the context of a system like GKS with relatively few levels of optionality this leads to 16 GKS support configurations (see Table 3). The functionality required to directly support these levels is detailed in Part 1.

Since each of the configurations is defined to address a paraticular group of users, the term "constituency profile" has been coined to capture the concept of "that function grouping required by this group of CGI clients". The method is anticipated as extensible, with new user com- munities defining groupings to suit their type of work and these new profiles being vetted through a type registra- tion procedure.

FUTURE DIRECTIONS Standards take time to develop. The origins of GKS (the Graphical Kernel System) can be traced to about 1974 although the ISO project did not officially start until 1979. Even so the standard was not finally published until 1985. The timescale for the CGI project is probably going to be only marginally shorter, with nationally based work during the initial stages of the project (from about 1981) within the USA (through ANSI X3H3) and an ISO project starting in 1985, projected to produce a standard at the end of 1989.

This length of project has important consequences on the standard's making process. The scope and goals of a project are defined during the initial stages and inevitable based on commonly conceived architectures at that time. After all standardization is often defined as formalization of 'the best of current practice'. However, with a rapidly developing technological base, the current practice is certain to be different by the time a standard is actually published. This leads naturally to a requirement for exten- sibility within standards, currently provided by registra- tion mechanisms etc. However, it also leads to the requirement to reappraise and potentially reinterpret the role of any proposal during the period of its development. The appraisal is often done unknowingly by the standards process itself. Anyone who deals with this for any length of time will recognise that very few people can sustain the voluntary work rate required of participants for more than a few years. Consequently, there is a significant turnover of personnel and the new people inevitably start with a slightly different perspective.

Each project, so far, seems to have been forced to reappraise its goals in terms of some major hardware develop- ments. With GKS the major development was probably the transition from the typical vector-based devices of the mid-1970s to the predominantly raster devices of the early 80s. For the CGI, the major transition has been from the era of terminal/host architectures to that of the window managed workstation networked both to others and to servers of different types. The second section described some of the commonalities between the different architectures but there are also some important differ- ences which will have to be addressed.

Probably the most important of these is the interaction between the CGI and window management systems. The


CGI, (as with the GKS or PHIGS workstation) addresses a single display surface which is assumed to have fixed resources, defined in a static description table. In window management systems, resources are shared among a number of independent views of the operator's interaction with the system. This amounts to a difference in the model of the system which receives a CGI data stream and ought to be solved by assumptions made as to the window manager's actions, and by a suitable reference model. Both of these are currently being worked on within the standards community 9'1°.

A secondary consideration is whether the CGI will provide the tools necessary to support a window management system, which is the inverse problem. The current intention is that it should, but some changes to the CGI may be necessary to provide the necessary high perfor- mance, particularly in the way clipping is supported.

CONCLUSIONS This paper has attempted to provide an overview of the proposed CGI standard as it is defined today and its implications for CAD systems. These implications are likely to be most felt in the portability of systems designed to use CGI devices. There are, however, a number of areas of functionality not provided in other standards, where systems which include their own graphics support or which have the knowledge that CGI devices are targeted by the graphics system, should gain efficiency by employing different display techniques. Most noticeable is the functionality provided in the raster part. In addition two addi- tional input classes will be standardised to allow raster input and the general input class. It is anticipated that such functionality would be addressed through systems such as GKS by proper use of registered Escapes, etc.

ACKNOWLEDGEMENTS Thanks are due to the many members of the international standards community who contribute in free discussion to the advancement of common understanding on which all standardisation relies. The helpful comments of the referees are also acknowledged.

REFERENCES 1 International Organization for Standardization

Information processing systems - computer graphics - techniques for interfacing graphical devices (CGI) functional description ISO DP 9636 (December 1986)

2 International Organization for Standardization Information processing systems - computer grahics - Graphical Kernel System (GKS) functional description ISO IS 7942 (July 1985)

3 Bono, P R 'A survey of graphics standards and their role in information interchange' IEEE Computer Vol 18 No 10 (October 1985) pp 63-75

4 Guedj, R A and Tucker H (Eds) IFIP Workshop on Methodology in Computer Graphics, Proceedings of Seillac t (1976) North Holland (1979)

5 Graphics Standards Planning Committee 'Status Report' Comput. Graph. Vol 13 No 3 (August 1979)

6 International Organization for Standardization Information processing systems - computer graphics - Programmer's Hierarchical Interface to Graphics (PHIGS) functional description ISO ISO DP9592 (Oc- tober 1986)

7 International Organization for Standardization Information processing systems - computer graphics - metafile for the storage of computer graphics (CGM) functional description ISO IS 8632/1 (1987)

8 International Organization for Standardization Information processing systems - computer graphics - Graphical Kernel System for Three Dimensions (GKS- 319) functional description ISO DIS 8805 (1986)

9 Steinhart, Jonathan E X3H3.6 Display management reference model ANSI X3H3.6/86/41 (September 1986)

10 International Organization for Standardization 150 TC97/SC21/WG2, Computer graphics reference model, working draft ISO SC21 N1402R (November 1986)


computer graphics interface and cad applications

Documents