317

GosiP: A GKS3D Shell for PHIGS

Michael French’

Abstract GosiP is an implementation of a GKS-3D level 2c interface to PHIGS. It allows GKS applications to run on PHIGS platforms, offering performance and portability across a wide range of high-performance 3D workstations. Compa- tibility of the standards is reviewed. A selection of design solutions is given for the problems of error processing, non-retained primitives and attribute management. The concepts of Workstation Display Session and atmbute state are introduced. Some comments are made on implementa- tion dependencies, performance and portability.

1. Introduction

1.1. Compatibility of API Standards The issue of compatibility between international standards for the Application Programmer’s Interface (API) has been one of great contention. Following the promotion of GKS’ to International Standard in 1985, attention focussed on the emerging 3D standards: GKS-3D2, and PHIGS3.

Suggestions were made to bring PHIGS concepts more into line with those of GKS-3D in the areas of works- tation control, attribute binding, and transformations4. A further proposal5 would have fully integrated PHIGS into the GKS ‘level’ structure as a true superset of GKS-3D. Considerable attention was paid to a revision of GKS3D which would add the PHIGS ‘name set’ attribute mechanism6-8. The question of migrating GKS-3D and PHIGS to a common system to be known as PHI-GKS, was also examined at great lengthg-’ I .

GKS-3D and PHIGS have emerged from the long process of discussion and revision, to become full Interna- tional Standards. They use different philosophies of picture creation and display and are expected to be utilized in dif- ferent fields of application. Deciding which API to use for a given application has been discussed by Bettels et aI.l2. There is no name set addendum for GKS-3D and no stan- dard based on PHI-GKS, though there is renewed talk of migrating the standards in the context of the component- framework mode1133 14.

‘Particle Bysics Department Rutherford Appleton Laboratory Didcot, Oxon OX I 1 OQX. UK Tel: 0235 82 1900 Fax: 0235 446733 Email: french@uk.ac.rl.v2 (janet)

Another line of analysis has evaluated the possibility of an interface layer, or ‘shell’, which would translate GKS and CKS-3D calls into the appropriate calls to PHIGS. The shell would allow GKS/GKS-3D application programs to run in a PHIGS environment. The viability of this approach was first examined by Arnold, Hall and Reynolds in 198515, they concluded that most of the functionality of GKS could be simulated by the shell and PHIGS.

Following a request from IS0 Working Group 2 in September 1986, a full functional specification for the shell was produced by ten Hagen, Rouwhorst and Kessener16. This document gave a brief summary of error handling, data structures, mapping GKS segments to PHIGS struc- tures, and GKS primitives outside segments (‘non-retained primitives’), followed by a list of the operations required for each GKS-3D function.

1.2. Motivation

The high energy physics (HEP) community in Europe uses GKS/GKS3D as its standard API. There is widespread expertise in GKS and a large investment in software applied to a range of data analysis applications. Raw experimental data is collected at particle collider facilities, ‘reconstructed’ using pattern recognition software then examined using interactive 3D ‘event displays’ based on wireframe representations of the data. There is a need for high performance 3D workstations to manipulate these images. It is clear that the hardware vendors are committed to PHIGS for 3D graphics, and there is no single imple- mentation of GKS3D which has device-drivers for all the latest super-workstations.

By 1989 the API standards had been established; the ten Hagen et al. specification was several years old; the market for powerful graphics workstations to run GKS applications was very restricted; and the first results were expected from the new particle colliders - LEP at CERN in Geneva (1989) and HERA at DESY in Hamburg (1990). The GosiP project was established to implement the shell and thus provide portability for GKS3D applications across the new generation of high performance worksta- tions.

1.3. Formulation of the Shell The design of GosiP is closely based on the specification of ten Hagen et al, some use was made of the methods described by Arnold et al, and several areas were corrected, extended or formalized by the author. A full description of the shell will not be given here. Instead, the major features

North-Holland Cornpurer Graphics Forum 9 ( 1990) 3 17-326

318 M. French ' G o v f : A GKS-jD Shrllfhr PHlGS

will be summarized, then three design topics (error process- ing, primitives outside segments, attribute management) will be studied more closely in the next section. The gen- eral architecture of a graphics system using the shell is shown in figure I . A knowledge of GKS and PHIGS is assumed in the descriptions that follow. Function names are taken from the Fortran bindings, there is a glossary of abbreviations at the end of the paper.

PHIGS

device

Figure I . Graphics system using the shell

The shell needs to maintain many data structures corresponding to those pans of the GKS structures not present in PHIGS. Several of these structures are extended with shell specific items. The GosiP data dictionary comprises: Shell Operating State (SOS); Shell Description Table (SDT); Shell Error State List (SESL); Shell State List (SSL), without the event queue and current event report; Shell Workstation State Lists (SWSL), considerably reduced; and the Shell Segment State List (SSGSL). The workstation description tables are maintained by PHIGS.

PHIGS has no concept of activating/deactivating a workstation, so the shell simulates this by posting struc- tures to workstations. See section 2.2.

The PHIGS output pipeline can completely suppon that of GKS-3D. The GKS normalization transformation (NT) is simulated with a PHIGS local modelling transfor- mation, and the normalization clip (Nclip) is simulated with a PHIGS modelling clip. The workstation dependent parts of the pipeline (view orientation, view mappingfprojection, view clip, workstation transformation and clip) are identical in the two standards. The NT table is administered by the shell, and the inverse NT must be applied to locator and stroke input. The transfornation matrices require a format conversion. See S i n g l e t ~ n ' ~ , 1986, and revisions, for more details.

Each GKS segment is stored in a single PHIGS struc- ture. The structure is logically divided into three sections: segment attributes, simulated using PHIGS global model- ling transformations and name set operations; an output attribute header, comprising NT, Nclip, Aspect Source Flags, and primitive attributes; finally the 'dynamic' section where output primitives and resettings of the output attri-

butes are written. Thus all segments are stored in the PHIGS Central Structure Store (CSS). Segments are associ- ated with workstations. i.e. put into Workstation Dependent Segment Storage (WDSS). by posting the appropriate PHIGS structure to the workstation. Workstation Indepen- dent Segment Storage (WISS) is purely an administrative device maintained by the shell within the CSS. The Shell WISS Workstation State List (SWWSL) is kept entirely by the shell.

A GKS Annex E Metafile workstation would have to be completely supported by the shell. GosiP does not yet support this feature.

The GKS-2D subset can be implemented on GKS-3D. or directly on PHIGS, using its own 2D routines.

2. Design Topics

2.1. Error Processing Error states occuring within the graphics system are reported to the user via the error processing chain. Error processing is treated in the same way in GKS and PHIGS, except that PHIGS has a minor extension to allow error handling to be switched off. The GKS hierarchy is shown in figure 2 .

program routines

errur

FUNCTION KAMES

{ errur report }

I error { message string }

m 5 n g ERROR FILE ERROR MESSAGES

where E = { CKS error code, GKS function id, error file }

Figure 2 . Daiajlow for GKS error processing

Some error checking is done in the shell (e.g. Shell Operating State), while the rest is left to PHIGS. The shell error processing must merge these two sources of errors and simulate GKS error handling and logging. An applica- tion can substitute for the 'transparent' error handling rou- tine provided by the standard (GERHND in GKS; PERHND in PHIGS). The shell performs this substitution for the PHIGS error handler, and must allow for substitu- tion of an external handler by a GKS application. Arnold et

M. Fretdi I GosiP. A GKS-3D Shrflfor PHlCS 31’)

al. reported the substitution of the error handler by the application as an “insoluble” problem, and ten Hagen et al. considered i t to be “virtually impossible”.

The error processing in the shell is divided into four stages: detection, classification (or primary error handling). handling, and logging, see figure 3.

GKS routines in the shell set their name in the Shell Error State List (SESL). On detection of an error the pri- mary error handler (SERHND) is called with a parameter set (q) containing a flagged value of the function identifier (say -1). The primary error handler is also substituted into PHIGS and receives the errors detected there with the stan- dard PHIGS function and error codes (9. Primary error handling replaces the original function identifier in the parameter sets with the GKS value from the SESL, and converts PHIGS error codes to their equivalent GKS or shell specific values. Then the primary handler calls the standard GKS handler (GERHND) with the usual argu- ments (G). The shell GKS error handler is transparent, it simply calls the shell GKS error logger (GERLOG) which reports the error to the error file. A facility is provided by the shell to allow the primary error handler to call the PHIGS error logger, so that the original PHIGS error mes- sage can also be reported. This optional branching is con- trolled by the Shell PHIGS Error Logging Flag in the SESL.

r F - l [G.....j / -Fr- / 1 App. G K S PHIGS 1 program routines routines -*-

Optional substitution I error } - - - - - - - :

handling by ; application I

; I Optional

error error handling handling

GERLOG PERLOG PHICS

error error

logging logging ERROR FILE I

t , I - - - - - - _ _ - - - - - - _ _ - - _ - - - - +

where and

SESL : Shell Error State List C = { GKS error code, GKS function id , error file } F‘ = { GKS error code, shell flag, error file } P = { PHIGS error code, PHIGS function id, error file }

Figure 3. Dataflow for GosiP error processing

I t is important that the checking of every GKS error and the translation of every PHIGS error be comprehen- sive. Error ‘traces’ have been constructed to chart the error behaviour of every GKS routine. The first steps are to decide whether a particular GKS error is to be checked by the shell or by PHIGS. and to decide on the translation of every PHIGS error to the corresponding GKS error. Ambi- guity for PHIGS errors which can translate into several GKS errors is resolved by referring to the GKS function where the error originated. Thus a conversion routine can be written which takes the PHIGS error number and GKS function id as inputs, and returns the appropriate GKS error number. This routine can be used independently for uansla- tion of error indicators in inquiry functions. The standards documents specify the errors which can be generated by each function, and the ten Hagen et al. specification lists the PHIGS calls made by each shell GKS routine. These live lists can be combined to form the error trace of each GKS function, and hence show that the shell is correctly simulating the error processing of GKS, see figure 4. In addition, the order of checking and the inter-dependency of errors must be considered, this usually results in more error checking being done in the shell than first expected.

Figure 4 . Error tracing example

2.2. Non-retained Primitives CKS primitives outside segments are displayed at creation time, subject to the deferral state, on all active output workstations, but ‘non-retained’ following picture regen- eration. The only non-retained primitives visible on a workstation are those created since the last picture regen- eration on that workstation. All primitives outside segments are stored in a single PHIGS structure, the Non Retained Structure (NRS). The NRS is created and initialized, with the current attribute values from the Shell State List (SSL),

531 .M French i GnsiP: d GKS-3D Shellfor PHlGS

when the first output or WISS workstation is opened. It is deleted when the last such workstation is closed.

In dealing with the visible sections of the NRS, it is convenient to introduce the concept of a Workstation Display Session (WDS), which formalizes and extends a technique used by ten Hagen et al. A WDS is an interval between successive picture regenerations on a particular workstation. Each WDS has a unique integer identifier. Every open output workstation has a current WDS, its identifier and state are kept in the Shell Workstation State List (SWSL). The WDS state can rake any of four enumerated values: absent (i.e. undefined); active: suspended; or stopped. Transitions between these states are caused by picture regeneration (GUWK, GCLRWK, GRSGWK, GSDS) and by certain changes in the operating or workstation states (GOPWK. GCLWK, GACWK, GDAWK. GCRSG, GCLSG). After a WDS has been started on a workstation, possibly in a suspended state, i t can pass through an arbitrary number of interleaved active and suspended phases before being stopped. Only primi- tives in active sections of the current WDS on an open out-

created and manipulated by ;I simple GKS program control- ling one workstation.

Visibility of non-retained primitives is controlled by using the PHIGS name set attribute and the workstation invisibility filters. A dummy name (wds-0 in fig. 5 ) is used to 'reverse' the filters, such that the default attribute is invisible and a second name can be used to switch on the visibility. When a WDS is started its identifier is placed in the invisibility exclusion set and a structure element is writ- ten to the NRS which adds its identifier to the name set (FADS). A WDS is suspended by writing an element to the NRS removing the identifier from the name set (PRES). Note that primitives created while the WDS was active remain visible following WDS suspension. If a picture regeneration is requested while a segment is open, the suspended WDS is stopped and a new WDS is started in a suspended state. Usually the picture will not be regenerated while the segment is open and two unnecessary, consecu- tive name set elements will appear in the NRS for each active workstation. More examples are shown in figure 5 , independent use of the filter sets to control segment visibil-

put workstation are visible. Figure 5 shows how WDS's are ity has been omitted for clarity.

G K S Workstation Non-Retained Invisibility Functions Display Session Structure Filter S e t s

name action incl, cxcl

~ COPKS 1 GOPWK

set attnbute 1 GACWK pnmrtrue 1 GCLRWK

pnmrtrue 2 GCRSG

pnmitiue 3

GRSGWK

set altnbute 2 GCLSG

pnmrtrve 4 GDAWK GCLWK GCLKS

* _ _ _ _ _ + I wds.1 I startlsuspend

resume

wds.1 stop H wds-2 start

I suspend I

open & post XKS header :

... set NT, Nclip

... set ASFs ... set nttnbutes

PADS(wds-O] set attnbute 1

PADS( wds.1) pnmrtzue 1

PRES( wds-I)

pnmitiuc 2 PRES (wds-2)

close NRS

_ - - _ _ - - _ - _ _

PADS(wds.Z]

set attribute 2 i P.ADS(wds.3) _ _ - - - _ _ - - _ -

Iwds.0). { w d s d }

{wds-O}, { } {wds-fl), {wds-3}

pnmitrue 4 PKES( wds-3)

1 I

1 1 I suspend

4 wdsJ ' stop close & delete SRS {Wds-O), { } + _ _ _ _ _ I

Figure 5. Workstation Displuy Sessions and the Pion Retained Structure

M . French / GosrP: A GKS-3D Shellfor PHIGS

GKS Control Functions

GOPWK(wk1) CACWK(wk1) GO P WK( w f 2 ) GACWK(wf2) GOPWK(wk3) CACWK(wk3) GCLRWK(wk1) GCRSG GUWK(wk3) GCLSC GRSCWK(wk2)

Workstation Display Session Non Retained Structure wkl wk2 wk3

1 I U visible on , - - - - - - - , ’ at least one i I I I wds-6

Figure 6. WDS handling with multiple workstations

In general, for multiple workstations, the NRS is com- posed of many overlapping WDS’s. Non-retained primi- tives can then belong to one or more WDS’s. Picture regeneration cannot be forced on all workstations at once, so concurrent WDS’s will not have the same start and stop points, this enables WDS identifiers to be allocated using a simple integer counter. Creating a segment suspends all active WDS’s, closing the segment resumes those WDS’s. Note that a workstation can be opened but not activated while a segment is open, this agrees with restrictions in the GKS standard. The multiple workstation situation is illus- trated schematically in tigure 6.

A non-retained primitive in the NRS will be redun- dant when each workstation on which it has been displayed has undergone picture regeneration. This means that every WDS to which it belongs has been stopped. The redundant section of the NRS extends from the end of the header sec- tion to the beginning of the oldest current WDS. When WDS names are taken from a simple counter, this will be the current WDS with the lowest valued identifier. The redundant region of the NRS is shown in figure 6. A PHIGS label structure element, using the WDS identifier. is written into the NRS at the beginning of each WDS (not shown in figure 5) . The redundant sequence of structure elements can be deleted using these WDS labels within the NRS. It is probably most convenient to conduct this purge when a picture is regenerated. When there is only a single output workstation, the NRS can be purged at every picture regeneration by deleting structure elements belonging to the previous WDS.

2.3. Attribute States and the Non Retained Structure

Attributes which have the PHIGS default values are automatically handled correctly by the PHIGS traversal process. Their values in the Traversal State List are initial- ised from the PHIGS Description Table and remain unchanged during traversal. There are no structure elements

I 1

to set these attributes. The shell does not need to take any action to ensure that these attributes are accurately reflected on the display.

In general, the current attribute values are stored in the Shell State List (SSL). Structure elements to set these attributes must be written into the NRS so that the non- retained primitives are displayed correctly. A header sec- tion is written to the NRS, when it is created, to initialise the modelling transformation and clip, Aspect Source Flags, and primitive attributes according to their current values in the SSL. Attributes can be set while a segment is open, but the structure element written at that time will be sent to the segment structure, not the NRS. When the seg- ment is closed, the NRS is re-opened, the current WDSs are resumed, and the NRS must be updated with structure ele- ments to set the new current attribute values. This can be achieved by always resetting all the attributes to their current values, but this would reset many attributes unnecessarily.

When the NRS is purged the attributes set in the redundant WDS(s) must be incorporated into the NRS header. This can be accomplished by using structure ele- ment inquiries to find all the ‘set attribute’ elements, and then using structure editing to re-write the appropriate ele- ments into the NRS header. In general, the re-set values will only be the current values, as recorded in the SSL, for the single workstation case.

In an attempt to increase the efficiency of these attri- bute update operations and purges, a system of attribute states was introduced. Each of the ‘attributes’ appearing in the NRS header (i.e. including modelling transformation& clip, ASFs etc) has a state flag which can take one of four enumerated values: PHIGS default value (SPHDEF); non- default values recorded in the SSL only (SSSL); realized by a structure element in the NRS header (SNRSHD); and realized by a structure element in the body of the NRS

M. French / GosiP. A GKS-3D Shelljiir PHIGS

GS while GKOP o r

SGUP

GS whrlt WSOP 0 2

WS‘K I I

07

GCLWK (delete NRS)

Recorded in SSL,

- NRS header element

GS while

WSAC

(Purge NRS) WSOP or

- SNRSBD ~ Realized -

I rl ’ I

Gs while WSOP o r

WSAC

NRS body element

GCLSG GOPWK (create YRS) (updare NRS)

CS while SCOP

~

GCLSG GOPWK (create YRS) (updare NRS)

CS while SCOP

Figure 7. Attribute stutes und transition events

(SNRSBD). The attribute states are stored in the SSL, and set by the ‘GKS Set attribute’ functions (GS ...) depending on the Shell Operating State when the function was invoked. The allowed states and transitions are shown in figure 7. States are represented by the labetled boxes and the transitions caused by certain functions in the context of the operating state are shown by the mowed pathways between the states.

When GKS is opened, the operating state becomes GKOP, the attributes in the SSL take the PHIGS default values, and all attribute states are SPHDEF. While the operating state is GKOP, there is no open structure, no structure element can be written, so if attributes are set. the attribute state becomes SSSL. When the first workstation is opened, the operating state becomes WSOP, the NRS is created and initialised, all attributes flagged as SSSL have their non-default values realized in the NRS header and their flags changed to SNRSHD. Subsequently, while the operating state is WSOP or WSAC (when a workstation is activated) attributes are set by writing a structure element into the body of the NRS and the attribute flag becomes SNRSBD.

When a segment is opened, the operating state becomes SGOP, the NRS is closed and a segment structure is ope’ned. If an attribute is then set, a structure element is written into the segment structure, the value is stored in the

SSL and the attribute flag becomes SSSL. When the seg- ment is closed. all attributes in state SSSL are updated in the body of the NRS with a new structure element, and their states changed to SNRSBD. In the simple case with only one output workstation open, a purge can be per- formed by deleting the redundant section of the NRS, reset- ting all those attributes in state SNRSBD by editing the header and changing the states back to SNRSHD. This simple attribute state scheme allows efficient management of the NRS.

For the general case with many output workstations open, there is no simple attribute state flagging system which can be used to perform the NRS purge, and the shell must resort to structure element inquiries.

3. Implernentational Considerations

3.1. Dependencies

The GosiP interface provides nearly all the functionality of a conventional GKS-3D level 2c implementation. The shell has been designed and coded for multiple workstation implementations of PHIGS, it contains the full 2D subset. and complete error handling facilities. The entire GKS-3D output pipeline is supported. The GosiP kernel comprises over 280 functions implemented in about 10,000 lines of Fortran-77. The project represents approximately 6 man- months of effort - starting without any experience of PHIGS, the hardware development platform or its operating system. Benchmarking and porting of applications have not been included in this estimate.

GosiP has some omissions: there is no GKS Annex E metafile workstation; the five pixel and text extent inquiries are not supported. There are also a few areas of non- standard behaviour, perhaps the most important being deferral states. When GKS picture regeneration is suppressed, the shell uses PHIGS modes ‘wait - update pic- ture without regeneration’, except when GKS deferral mode is ASAP, then PHIGS is allowed to use quick update method to effect picture changes without traditional regen- eration. This minor extension to GKS for deferral mode ASAP is largely a matter of taste, it is not clear how the idea of ‘suppressed regeneration’ should be generalised when simulated methods are available. When GKS regen- eration is allowed, the shell can simply use the GKS defer- ral modes directly in PHIGS. GKS inquiries of dynamic modification for workstation and segment attributes are allowed to return the PHIGS value ‘Can Be Simulated’ together with a shell specific ‘passive’ error indicator. The enumerated value (GCBS=2) has been added to the GosiP include files. Methods of interpreting the CBS value in a workstation dependent way based on current deferral states were rejected as too confusing to the application, incompa- tible with multiple workstation implementations and because they restrict the operating state to be WKOP or greater at inquire time.

M . French I GosrP: A GKS-3D Shellfor PHIGS 313

A functional restriction to prevent picture regenera- tion while a segment is open was introduced for perfor- mance reasons (see 3.2). since this feature is not used in our applications. Other interesting GKS ‘features’, including the changing of clip volume when inserting segments, have been faithfully implemented. Shell data structures are lim- ited by parameters in the Shell Description Table, most of which are, in turn, dependent on the particular PHIGS Description Table. One additional restriction is that seg- ment names have to be chosen from the range of allowed numbers of segments, this is to simplify and speed up access to the Segment State List. This mechanism is the same as the standard treatment for NT numbers, but the shell does allow arbitrary integer values for workstation identifiers.

The functionality provided by GosiP will usually be most severely restricted by incompleteness in the underly- ing PHIGS implementation. For instance. Apollo Domain/PHIGS l 8 is a single workstation implementation. allowing GosiP to support only one workstation plus WISS, this is a considerable restriction for some of our applica- tions. The Apollo implementation also lacks features such as modelling clip, pattern interior style, full cell array prim- itive, echoless input and variable line width, of these, only the last two cause some inconvenience in our current appli- cations. But there are several major extensions which can usually be offered by GosiP output to CGM (Computer Graphics Metafile) or a common format of print file; a interface to PEX (PHIGS Extension to X-Window) for networked 3D graphics: and additional colour models such as HSV (Hue Saturation Value). The CGM output is some compensation for the absence of a GKSM workstation and the different colour models are expected to become more important as our applications evolve.

In conclusion, the implementation is a full one. only a tiny number of routines are not supported, these omissions have not caused us any problems. The few functional res- trictions imposed by the shell are not serious, they are usu- ally less important than those caused by omissions in the underlying PHIGS implementation. In this respect GosiP achieves the definition of GKS-3D application compatibil- ity set out in Arnold et al. l 5 and reiterated in ten Hagen et aI. 16:

‘‘ ... that level of compatibility which could be expected in transporting between two different GKS implementations.”

3.2. Performance

GosiP was intended to be used on powerful 3D graphics workstations and it is very important that the overall perfor- mance for GKS applications remains good. Graphics per- formance for 3D applications is difficult to quantify and analyse, evaluation here will be in three parts: general dis-

cussion; benchmark results for Apollo workstations: and finally some methods employed to improve NRS traversal.

While writing the shell, emphasis has been placed on the clarity and functional correctness of the code. For instance. the shell has been written to allow the use of mul- tiple workstations and there are clear performance disad- vantages in catering for many workstations if only one is available from PHIGS.

The provision of full error handling facilities is essen- tial for application program development, but contributes a low level overhead in all routines.

The ‘administrative’ actions for GKS and its worksta- tions (open, close, activate, deactivate, clear, update) are much slower than for pure PHIGS, but these functions do not occupy a large proportion of the time taken to run any given application.

There will be a small tixed overhead in each call to an output primitive, due to the error checking done in the shell. The significance of this delay for lines, markers and fi l l areas will become smaller as the number of points passed to the primitive increases. with a vectors/sec meas- urement approaching that of PHIGS for large polyline calls.

For typical application programs the bottleneck may well be segment handling functions, especially create or close segment. Copy and insert segment will also be slow but these are probably not critical to program performance. Associate segment will be relatively fast, consisting of some error checking and the ‘PHIGS POST STRUCTURE‘ command. Each segment-structure has to be initialized with a structure element for each attribute with a non-default value, so the shell can be inefficient for display of many small segments.

In general. the inefficiency of constructing pictures in a fragmented way (few vectors/polyline; few polylines/ segment), which has been demonstrated in GKS bench- marks19, will become more pronounced with use of the shell.

Benchmarks have been performed on three Apollo workstations : DN3500, DN4500VS and DN10000VS. The test program made cpu timing measurements for drawing, regenerating and transforming (rotating) a 5000 vector pic- ture. Many different picture compositions were tried i.e. different numbers of segments and primitives were used to depict the same test picture. The polyline primitives had PHIGS default attributes and the rendered vectors were estimated to have a mean length of 10 pixels. Results for the transformation test on Apollo DN4500VS are shown in figure 8. The basic loop for transformations consisted of evaluating the view mapping matrix (GEVVWM), check- ing for an error, then setting the view representation (GSVWR). The view was changed 20 times for each timing measurement, giving a total of 100,ooO transformed vectors for each result.

no. of primltlve per segment

Fi<qirrr 8. Apollo DN45OOVS Benchmark

Figure 8 shows how the performance decreases as the picture is dispersed among more segments (moving down the set of curves), and as the picture is fragmented within segments (moving along same curve). The results for the DN10000VS workstation show similar structure, with a peak performance of 250 kvec/sec. The DN3500 gives less dependence on the number of segments and a peak rate of 4.3 kvec/sec.

The event display for the OPAL experiment (one of four on the LEP collider) has been installed on an Apollo DN IooOOVS at Manchester University using the GosiP library. The display uses complex wireframe pictures which are fragmented into many primitives and segments to allow flexible interaction (especially pick). The system is rela- tively slow to draw these fragmented pictures into WISS. but, once the picture has been constructed, 3D manipulation is certainly fast enough to give smooth changes of view under user control.

Non-retained primitives impose a large burden on the shell. Three methods have been employed to reduce the size and complexity of the NRS and hence reduce structure traversal time. The first measure eliminates the need for a 'PHIGS SET ...' structure element to appear in segment structures, or the NRS, if either: a new attribute value is the same as the old: or the attribute has the PHIGS default value.

The second technique is to purge the NRS of redun- dant elements. For single workstation implementations of PHIGS a purge is performed each time the picture is regen- erated, using the attribute states described in section 2.3.

Thirdly, the NRS name set operations generated by opening and closing segments (see 2.2) have been removed. The gain in performance is achieved at the expense of a functional restriction: the picture cannot be regenerated while-a segment is open. This is a standard facililty but is not used in our applications.

The NRS does impose a burden on the shell and its operations are somewhat slower than a conventional irnple- mentation, but most large applications will use segment manipulation rather than build complex non-retained pic- tures.

3.3. Portability

The GosiP libraries are divided into two layers. The top layer or 'kernel' contains the bulk of the code, it converts GKS-3D calls to those of standard PHIGS. These calls are passed to a skeleton PHIGS interface which has been fleshed out with code to compensate for any non-standard behaviour in the underlying PHIGS implementation. Thus the PHIGS implementation-specific code is localized within its own 'thin shell'. At present GosiP has thin shell PHIGS interfaces for Apollo Domain/PHIGS'X and DEC PHICS"'. Clearly the effort involved in any port of GosiP will depend on how the closely the particular PHIGS product follows the standard.

4. Conclusions

A GKS-3D shell has been implemented for PHIGS. The practical difticulties of translating between the two API standards have been overcome.

Of the design topics described. the error processing solution is very important. but specific to the shell. The attribute state mechanism is a useful way to control appear- ance of output primitives in an environment where setting. storage, and realization of attribute values are distributed among many parts of the graphics system. The concept of a Workstation Display Session is perhaps the most significant. since i t describes a fundamental unit of display within the CKS system in terms of simple states and their transitions.

GosiP is a full implementation of the shell concept. with relatively few internal restrictions. Performance has been benchmarked and tested with real applications used in particle physics experiments. My general conclusion is that the shell approach has been vindicated. The unsatisfactory features which remain have been localised as far as possi- ble, tested and described in the body of this paper. The functional coverage and 3D performance of GosiP will meet the requirements of many large applications written in

There are several directions in which the GosiP software can be taken forward, including the addition of a GKSM workstation handler. But most importantly. the software can be ported to other implementations of PHIGS.

GosiP extends the principle of portability within one standard to allow portability between standards.

GKS-3D.

5. Acknowledgements

This work is the result of a collaborative project between

RAL and HP/Apollo ( U K ) , who provided the workstations and DomainPHIGS on which GosiP was developed. Par- ticular thanks to Mike Drake. Colin Evans, Eugene McLaughlin and John Fisher.

The author would also like to thank Paul Jeffreys for supervising the project; Nick Hill for his help with project definition; Karl Palmen for implementing the GKS-2D sub- set: Martine Dejode for testing GosiP and porting it to DEC PHIGS; John Allison and John Banks for braving the ins- tallation of GosiP with the OPAL event display and helping with benchmark tests.

Many valuable comments were received during the design of GosiP, special thanks to David Duce. Toby Howard, David Myers, Chris Osland, Adib Romaya, and the Apollo Engineering Group.

The author is also grateful to the referees for their comments and suggestions.

References

1.

2.

3.

4.

5 .

6.

7.

8.

9.

International Organisation for Standardisation (ISO), “Information processing systems - Computer graph- ics - Graphical Kernel System (GKS),” IS0 7942, IS0 Central Secretariat (August 1985).

International Organisation for Standardisation (ISO), Graphical Kernel Sysrem f.r T h r r Dimensions ( G K S 3 D J . I S 0 IS 8805, 1988, Functional Descrip- tion. IS0 IS 8806-1, 1988, Language Bindings: (Part I ) - Fortran.

International Organisation for Standardisation ([SO). Programmer’s Hierurchicnl Gruptrics System (PHIGSJ. IS0 DIS 9592-1. 1988, Functional Description. IS0 DIS 9593-1, 1988, Language Bind- ings: (Part I ) - Fortran.

J . Schoenhut, “Are PHIGS and GKS Necessarily Incompatible?,” IEEE Compurer Gruphics & Appli- carions 6(7), pp. 51-53 (July 1986).

J. Steinhart, GKS Lelvei 3 Proposal. I S 0 TC97/SC5/WG2 N309 (1984).

D.A. Duce, F.R.A. Hopgood. “GKS-3D and Filters,’’ BSI Doc 86/67015 (September 1986). International Organisation for Standardisation (ISO). GKS-JD Name Set Facility Addendum. Iso/TC97/SC2 I N 1455, Working Draft (April 1987).

M. Bakker, “Adding Namesets and Workstation Filters to GKS,” Computer Graphics F o r m 7( I ) , pp. 3-7 (March 1988).

s. Noll, J. Poller, J. Rix, “An approach to solve the compatibility problem between GKS and PHIGS.” CAD 19(8), pp. 456-463 (October 1987).

10. B. Shepherd, J. Rix, ”Issues raised by the PHI-GKS approach,” CAD 19(8), p. 464 (October 1987).

S. Noll, J. Poller, “PHI-GKS: an Implementation to Support GKS-3D and PHIGS,” Compurrrs & Graphics 12(2), pp. 163-172 (1988).

J. Bettels, P. Bono, E. McGinnis, J. Rix, “Guidelines for determining when to use GKS and when to use PHIGS,” Computer Graphics Forum 7(4), pp. 347- 354 (December 1988). J. Poller, S. Noll, J. Rix, “Migration of GKSEKS- 3D and PHIGS Discussed under the View of the Computer Graphics Reference Model,” Computer Graphics Forum 8(3), pp. 239-248 (September 1989).

14. D.A. Duce, “GKS, Structures and Formal Specitication.” Proceedings Erirographics ’89, North-Holland (1989). D.B. Arnold. G. Hall. G.J. Reynolds, “GKS Pro- gramming in a PHIGS Environment,” Compurer Graphics Forum 44), pp. 349-358 (December 1985).

P.J.W. ten Hagen, B.P. Rouwhorst, L.R.A. Kessener, A GKS Shrll jbr PHIGS Implrmmrurions, IS0 TC97/SC?I/WG2 N541 (March 1987). K.M. Singleton, “An Implementation of the GKS- 3DPHIGS Viewing Pipeline,” Proceedings Euro- gruphic,.~ ’86. North-Holland ( 1986). ApollolDomuin PHICS. \,ersiorr 1.0.1. Apollo Com- puter (April 1989). M. French, “A Benchmark Test for GKS-2D.” RAL Report 89-025 (March 1989).

DEC PHlCS Jiw V M S . version 2.0. Digital Equip- ment Corporation.

11.

12.

13.

15.

16.

17.

18.

19.

20.

Appendix 1.

A bbreviatiuns

API ASF CERN

CGM css DESY GKS GKSM GosiP

HEP HERA HSV LEP

Application Programmer‘s Interface Aspect Source Flag (GKS,PHIGS) European Organisation for Nuclear Research (Geneva) Computer Graphics Metafile Central Structure Store (PHIGS) Deutsches Elektronen Synchrorron (Hamburg) Graphical Kernel System GKS Annex E Metafile GKS-3D outer shell for implementations of PHIGS High Energy Physics Hadron Electron Ring Accelerator at DESY Hue Saturation Value colour model Large Electron Positron collider at CERN

.32fl

Nclip NRS NT OPAL

PEX PHIGS WDS WDSS WISS

Normalisation Clip (GKS) Non Retained Structure (GosiP) Normalisation Transformation (GKS) A particle physics expenment on the LEP col- lider PHIGS Extension to X-Window Programmer's Hierarchical Graphics System Workstation Display Session (GosiP) Workstation Dependent Segment Storage (GKS) Workstation Independent Segment Storage (GKS)

GKSlGKS3D function names

GACWK Activate workstation GCLRWK Clear workstation GCLSG Close segment GCLWK Close workstation GCRSG Create segment GDAWK Deactivate workstation GERHND Error handler GERLOG Error logger GEVVWM Evaluate view matrix GOPWK Open workstation GOPKS Open GKS GRSGWK GS ... GSDS Set deferral state GSVWR Set view representation GUWK Update workstation

Redraw all segments on workstation generic set attribute function

PHIGS function names

PADS PERHND PERLOG POPPH PRES

Shell internals

Operating state

Attribute state

Data Structure

Add name to set Error handler Error logger Open PHIGS Remove name from set

GKOP SGOP WSAC WSOP

SNRSBD

SNRSHD

SSSL SPHDEF

SDT SESL sos SSGSL SSL SWSL

SWWSL

GKS open segment open workstation active workstation open

realized by structure element in NRS body realized by structure element in NRS header value set in SSL only PHIGS default value

Shell Description Table Shell Error State Shell Operating State Shell Segment State List Shell State List Shell Workstation State List Shell WISS Worksta- tion State List