Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future

Guidelines and Recommendations

1. A Conceptual Framework

The most important result is the recognition and acceptance of the need for a clear distinction between a graphics subsystem {called also the core), and a modelling subsystem (sometimes called also the geometric subsystem).

The graphics subsystem should functionally provide two mechanisms:

A) A mechanism to process descriptive data
A mechanism to process descriptive data, given in a system of coordinates called world coordinates, only to achieve the proper display, i.e. it concentrates on the viewing aspects of computer graphics.
B) A mechanism to insure proper interaction
The graphics subsystem is, for the present, better characterized by what it functionally should not provide rather than by a precise description of its functions. The clear result is that it should not contain the functions attributed to the modelling subsystem.
The modelling subsystem does contain the model, and just those functions that deliver the coordinates of the point of a meaningful object, to the graphics subsystem, for viewing purposes. It should also contain functions for composing transformations, storing and retrieving the current transformation, and if transformations are stored using a stack, functions to push and pop the stack.
The Workshop warns that, depending upon the detailed specification of the graphics subsystem, certain types of hardware may not be fully exploited. Similarly, concern was expressed that certain applications, seeking to achieve maximum performance, might wish for a graphics subsystem with a different set of mechanisms, referred to by some participants as a hook.
The workshop participants assert that by making these distinctions, two important factors sought for application programs will be affected beneficially:
  • (F1) Transportability
  • (F2) Device Independence without a severe adverse affect upon:
  • (F3) Performance

Recommendation R1

The workshop urges a specification of the graphics subsystem as soon as possible.

The workshop feels that a preliminary draft of such a specification could be initiated, starting from the present work, by a working party of a smaller number of people. It is understood that such a specification shall not be the final activity; the normal and continuous but deliberate process of evolving standards applies also to the graphics subsystem. Subsequent revisions might relax the conditions given in the above warnings.

It is hoped, under such circumstances, that the more immediate need for a standard can be met.

Recommendation R2

The workshop recommends that the specification of a modelling subsystem for a simple but widely used class of applications, be undertaken simultaneously (if possible by the same group which will address the specification of the graphics subsystem).

2. Identification of a methodology for design and implementation of application programs using computer graphics.

Transportability and device independence were also addressed from the user's point of view. What should be a recommended methodology for design and implementation of application programs which use computer graphics?

The workshop felt that the basis for such a methodology could be derived through a careful analysis of a representative set of all application programs and a subsequent categorization into what was called program, or skeletal, structures. A preliminary effort toward this goal was initiated, by a subgroup during the workshop.

Several relevant aspects were addressed.

A) The context of facilities
A context of the facilities configurations, in which application programs were to be analyzed for program structures, is determined to be necessary.
Facilities should satisfy the properties that facility configurations could be parametrically differentiated, and that they collectively spanned the universe of configurations.
B) The choice of a set of application programs using computer graphics
The application programs should be such as to be parametrically differentiated according to some user-oriented characteristics : collectively they should span the universe of graphics applications.
C) The way of handling the analysis
Analysis of applications and the design of corresponding program structures need to follow an orderly course suitably adapted from software engineering practices.
D) The time and effort needed to achieve the above
Derivation of the set of program structures corresponding to the set of useful combinations of applications and facility configurations is felt to be a process that will require more manpower and time than is likely to be available from a small group of people in a short period of time.

Recommendation R3

The workshop feels that this is a very promising area for practical results: applicable to design and implementation of application programs using graphics. The workshop encourages research in that direction.

3. The recognition of the need for formal specification techniques to be applied to graphics systems and concepts in computer graphics

Interactive computer graphics has long been an informal discipline; it should benefit from advances in computer sciences related to more formal disciplines like program correctness, structured programming; it should deal at the specification stage with formal abstractions {functions and data).

The workshop had a thorough presentation by a leading researcher in the field of specification techniques used to specify Data Abstractions.

The workshop recognizes the need for formal techniques to specify concepts unambiguously.

Recommendation R4

The workshop recommends undertaking an attempt at formal specifications of concepts and constructs in graphics systems.

Recommendation R5

The workshop suggest that any official proposal of a graphics package as a standard should be accompanied with a set of specifications which provide a reasonable level of formality.

4. Relationship with existing graphics packages

One subgroup of the workshop also addressed the issue of what was called an interim standard. This seeks to respond to those expectations, by the community at large, for immediately and practical recommendations by the workshop. The thread was to consider features of existing graphics packages. As an exercise two packages were examined; to see how they could be altered to improve portability and device independence. Features were characterized such that, when used, they would imply global differences or local differences in the same application using either one of the two packages. It was felt to be outside of the scope of the workshop to make recommendations directed to users of specific packages. However, from this analysis a recommendation could be made.

Recommendation R6

The workshop recommends that users, designers and implementers of graphics packages should carefully examine their packages to determine where they differ from the conceptual framework proposed here. They should indicate dangerous areas, and how they could be avoided.

Remark: Some packages could be reasonably transformed, to fit in the conceptual framework. This conceptualisation does not necessarily invalidate previous works, but seeks to clarify what the designers had in mind. Transportability should be added.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site