- Email: [email protected]
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 GKS2 and the paper highlights the areas in which the CGI currently differs in function or philosophy from GKS. UNDERLYING
ARCHITECTURAL
School of InformationSystems,Universityof EastAnglia, Norwich NR4
444
• 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 PHIGS6 proposals, nearing completion. Attempts at standardizing the DI/DD interface were only begun when GKS was sufficiently 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
MODELS
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 dramatic 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 7TJ,UK
for standardization can immediately be identified:
Time shared
host
-~ =
~ ~
Other users
Shared Dedicated (limited local processing)
i Grao,,..I terminal
Figure I. Typical CAD-graphics hardware configuration c. t975 'Number cruncher'
<3
Microfilm
t
service
I
I
I
I
1Other 1
E>
workstation:
Workstation Figure 2. Typica/ CAD-graphics hardware configuration c. 1987
0010--4485/87/080444--07 $03.00 (~) 1987 Butterworth & Co (Publishers) Ltd
computer-aided design
Application
Application
Dedicated
Graphics
Graphics
applications code
front end
front end
Graphics back end
Graphics back end
Operating system
workstation
Deviceindependent
Oedicated devicecontrol
j
Network
connection
front end
Devicedependent back end Device/window manager
Terminal hardware and software
C.
• Part 5 - input • Part 6 - raster
1987
c. 1975
Figure 3. Underlying components of the architecture in Figures I a n d 2 CAD database ] E.g. GKS from another manufacturer The Computer Graphics Interface
Figure 4. Relationshipbetween 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 pictures. 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
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 termination of a CGI session, setting the device to known default Workstation
-I Application Language Functional Workstation programs bindings standards software
Devices and
rnetafiles
11
s---t
J;
1
''
H
I
t I
I : _------El
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
volume 19 number 8 october 1987
CGI interface
Figure 5. Computer graphics standards interrelationships 445
Table 1. CGI output primitives
Table 2. CGI rendering attributes
Primitive c l a s s
Primitive class Individual only attributes
Primitives
Polyline Disjoint polyline Circular arc 3 point Circular arc centre Circular arc centre backwards Elliptical arc Polymarker Marker function Text Text functions Append text Restricted text Filled-area functions Polygon Polygon set Rectangle Circle Circular arc 3 point close Circular arc centre close Elliptical arc close Cell array Image functions Pixel array (described in Raster part) Generalized drawing GDP function Line functions
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, giving, 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 performance.
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 446
Bundled attributes
Line
Line type Line width Line colour Marker type Marker Marker size Marker colour Text attributes Character height Text font index Character orientation Text precision Text path Character expansion factor Text align ment Character spacing Character set index Textcolour Alternative character set index Interior style Fill attributes Edge visibility Fill reference point Fill colour Hatch index Pattern size 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 E
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 virtually 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.
computer-aided design
l lndividual I attributes
Stored graphic objects
I Bundled 1 attributes
The CGI defines two types of stored graphics object- segments and bitmaps (see Figure 7). Segmentation is a mechanism for the storage and manipulation of nonparametrized or partially parametrized descriptive definitions; bitmaps are used for the storage and manipulation of images or portions of images.
Segments
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,
Segment \
~-tore
Open Seg2 Set LW3 Polyline 3 Copy Seg 1 Polylme 4 Close Seg
U.. Pu I ~,,'--PL2
/
Individual [ - ~ - ' ~ attt'ibutes ~
Inheritance ~
,,,.r
\
f
\
PiSLW3 /
\
~
Segment store
Ir:bdividual~ Open Seg2 Set LW3 Polyline 3 Copy Seg 1 Polyline 4
PL3 ~PLIIC) ~PL2(C) ~PL4
Close Seg
ln.~,it~o~'--~-' \ ;~'~ / filter
"~ \
\ PI.2LW;~/ ~ Segment store
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).
volume 19 number 8 october 1987
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)). Primitives 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 fulldepth 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.
447
I Outinservicetoapplication
oo,y
\
~
oo,ou,oo,
FactoryJ. 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 resampling is performed in rendering the pixels. They correspond 1:1 to the pixels of the display bitmap irrespective 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)
448
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 cooperation 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 asynchronous 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 purposes). • 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 programming language. The parts envisaged will be
computer-aided design
Table 3. GKS Constituency profiles Profile
Workstation type
GKS level
GKSb GKSc GKS 0 GKS 1 GKS 0b GKS 1b GKS Oc GKS lc GKS bR GKS cR GKS OR GKS 1R GKS 0bR GKS lbR GKS0cR GKS lcR
In In Out Out Outin Outin Outin Outin In with Remote Echoing Input In with Remote Echoing Input Out with Echo Output Out with Echo Output Outin with Echo Output Outin with Echo Output Outinwith EchoOutput Outin with echo Output
b c 0 1,2 0b 1b,2b 0c lc,2c b c 0 1,2 0b lb,2b 0c lc,2c
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 communities defining groupings to suit their type of work and these new profiles being vetted through a type registration procedure.
FUTURE DIRECTIONS 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 convenient 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 constituencies, which should be taken into account in the formulation 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 contained 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
volume 19 number 8 october 1987
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 extensibility within standards, currently provided by registration 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 developments. 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 differences which will have to be addressed. Probably the most important of these is the interaction between the CGI and window management systems. The
449
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 performance, 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 additional 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.
REFERENCES 1 International
2
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.
450
for Standardization
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 (October 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 (GKS319) functional description ISO DIS 8805 (1986) 9
ACKNOWLEDGEMENTS
Organization
Information processing systems - computer graphics techniques for interfacing graphical devices (CGI) functional description ISO DP 9636 (December 1986)
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-aided design
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 GKS2 and the paper highlights the areas in which the CGI currently differs in function or philosophy from GKS. UNDERLYING
ARCHITECTURAL
School of InformationSystems,Universityof EastAnglia, Norwich NR4
444
• 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 PHIGS6 proposals, nearing completion. Attempts at standardizing the DI/DD interface were only begun when GKS was sufficiently 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
MODELS
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 dramatic 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 7TJ,UK
for standardization can immediately be identified:
Time shared
host
-~ =
~ ~
Other users
Shared Dedicated (limited local processing)
i Grao,,..I terminal
Figure I. Typical CAD-graphics hardware configuration c. t975 'Number cruncher'
<3
Microfilm
t
service
I
I
I
I
1Other 1
E>
workstation:
Workstation Figure 2. Typica/ CAD-graphics hardware configuration c. 1987
0010--4485/87/080444--07 $03.00 (~) 1987 Butterworth & Co (Publishers) Ltd
computer-aided design
Application
Application
Dedicated
Graphics
Graphics
applications code
front end
front end
Graphics back end
Graphics back end
Operating system
workstation
Deviceindependent
Oedicated devicecontrol
j
Network
connection
front end
Devicedependent back end Device/window manager
Terminal hardware and software
C.
• Part 5 - input • Part 6 - raster
1987
c. 1975
Figure 3. Underlying components of the architecture in Figures I a n d 2 CAD database ] E.g. GKS from another manufacturer The Computer Graphics Interface
Figure 4. Relationshipbetween 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 pictures. 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
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 termination of a CGI session, setting the device to known default Workstation
-I Application Language Functional Workstation programs bindings standards software
Devices and
rnetafiles
11
s---t
J;
1
''
H
I
t I
I : _------El
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
volume 19 number 8 october 1987
CGI interface
Figure 5. Computer graphics standards interrelationships 445
Table 1. CGI output primitives
Table 2. CGI rendering attributes
Primitive c l a s s
Primitive class Individual only attributes
Primitives
Polyline Disjoint polyline Circular arc 3 point Circular arc centre Circular arc centre backwards Elliptical arc Polymarker Marker function Text Text functions Append text Restricted text Filled-area functions Polygon Polygon set Rectangle Circle Circular arc 3 point close Circular arc centre close Elliptical arc close Cell array Image functions Pixel array (described in Raster part) Generalized drawing GDP function Line functions
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, giving, 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 performance.
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 446
Bundled attributes
Line
Line type Line width Line colour Marker type Marker Marker size Marker colour Text attributes Character height Text font index Character orientation Text precision Text path Character expansion factor Text align ment Character spacing Character set index Textcolour Alternative character set index Interior style Fill attributes Edge visibility Fill reference point Fill colour Hatch index Pattern size 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 E
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 virtually 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.
computer-aided design
l lndividual I attributes
Stored graphic objects
I Bundled 1 attributes
The CGI defines two types of stored graphics object- segments and bitmaps (see Figure 7). Segmentation is a mechanism for the storage and manipulation of nonparametrized or partially parametrized descriptive definitions; bitmaps are used for the storage and manipulation of images or portions of images.
Segments
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,
Segment \
~-tore
Open Seg2 Set LW3 Polyline 3 Copy Seg 1 Polylme 4 Close Seg
U.. Pu I ~,,'--PL2
/
Individual [ - ~ - ' ~ attt'ibutes ~
Inheritance ~
,,,.r
\
f
\
PiSLW3 /
\
~
Segment store
Ir:bdividual~ Open Seg2 Set LW3 Polyline 3 Copy Seg 1 Polyline 4
PL3 ~PLIIC) ~PL2(C) ~PL4
Close Seg
ln.~,it~o~'--~-' \ ;~'~ / filter
"~ \
\ PI.2LW;~/ ~ Segment store
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).
volume 19 number 8 october 1987
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)). Primitives 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 fulldepth 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.
447
I Outinservicetoapplication
oo,y
\
~
oo,ou,oo,
FactoryJ. 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 resampling is performed in rendering the pixels. They correspond 1:1 to the pixels of the display bitmap irrespective 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)
448
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 cooperation 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 asynchronous 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 purposes). • 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 programming language. The parts envisaged will be
computer-aided design
Table 3. GKS Constituency profiles Profile
Workstation type
GKS level
GKSb GKSc GKS 0 GKS 1 GKS 0b GKS 1b GKS Oc GKS lc GKS bR GKS cR GKS OR GKS 1R GKS 0bR GKS lbR GKS0cR GKS lcR
In In Out Out Outin Outin Outin Outin In with Remote Echoing Input In with Remote Echoing Input Out with Echo Output Out with Echo Output Outin with Echo Output Outin with Echo Output Outinwith EchoOutput Outin with echo Output
b c 0 1,2 0b 1b,2b 0c lc,2c b c 0 1,2 0b lb,2b 0c lc,2c
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 communities defining groupings to suit their type of work and these new profiles being vetted through a type registration procedure.
FUTURE DIRECTIONS 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 convenient 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 constituencies, which should be taken into account in the formulation 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 contained 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
volume 19 number 8 october 1987
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 extensibility within standards, currently provided by registration 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 developments. 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 differences which will have to be addressed. Probably the most important of these is the interaction between the CGI and window management systems. The
449
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 performance, 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 additional 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.
REFERENCES 1 International
2
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.
450
for Standardization
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 (October 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 (GKS319) functional description ISO DIS 8805 (1986) 9
ACKNOWLEDGEMENTS
Organization
Information processing systems - computer graphics techniques for interfacing graphical devices (CGI) functional description ISO DP 9636 (December 1986)
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-aided design