GRIP(ID:5650/gri005)for GRaphical Interactive Programming People: Related languages
References: DOI Extract: Introduction INTRODUCTION Over the years a number of FORTRAN subroutine packages for computer graphics have been implemented. In a number of papers, language extensions for computer graphics have been proposed. It is not just by chance that subroutine packages for computer graphics are widely used, whereas proposed language extensions are usually not generally accepted. The main reason for this is that a subroutine package can always be easily added to an existing compiler, whereas an extension requires major modification or a rewriting of a compiler. The approach of providing a display procedure package instead of a language extension, pragmatic as it is, has one shortcoming. It does not offer the possibility of introducing new data types and, hence, it rules out language constructs in which graphic objects may function as variables of expressions and statements. Therefore, a package of special procedures is not the proper approach if one wants to compose pictures by applying algebraic operations on graphics primitives (this is done, for example, in PDL or similar picture description languages)- Hence, graphic procedure packages are appropriate and convenient for generative computer graphics but not for the relational-descriptive approach or for what we may call "inferential" graphics. The primary justification for the dominant use of FORTRAN subroutine packages for graphics programming systems lies obviously in the fact that FORTRAN is the most commonly used language and that, in the case of stand-alone graphics systems, the small-scale to medium-scale computers used as the dedicated sole processor in the system has FORTRAN as the only high-level language available anyway. Authors of papers dealing with the design of subroutine packages for (or the extension of) languages other than FORTRAN will never hesitate to emphasize the advantages of their chosen language over FORTRAN, but it seems that very little attempt has been made yet to compare the most eligible languages systematically. More than FORTRAN, we consider PL/I, APL, and ALGOL (or ALGOL- like languages like, for instance, PASCAL) to be the most eligible languages whose suitability to function as a host language for display programming shall be discussed. In the course of this discussion, we should consider the fact that in actual computer graphics applications the ability of a language for constructing and managing data bases is equally or even more important than its ability for writing picture-generating programs. The reason why we shall, nevertheless, dwell more on the picture-generating aspects rather than the data base management aspects is that in the latter case the language capabilities are fairly well understood, whereas in the former case it appears necessary to study first the interrelationship between picture structures, data structures, language structures, and the mechanism of picture specification in order to identify the required capabilities. Generated pictures can be classified into two cases, namely: Program-created pictures (plotting) and interactively created pictures. Whereas the former case is relatively straightforward, the latter case includes the "attention handling" mechanism, and the associated program structure is affected by the choice as to whether all steps of an interactive procedure are directly controlled by the main program or whether we have an "intelligent" terminal with some global directives, whereat the individual steps of a procedure are controlled and executed locally. Extract: Picture Structure Picture Structure The task of a programmer who has to write a program for the generation, identification, and manipulation of graphics objects displayed on a CRT screen will be considerably simplified by a picture structure that enables him to deal globally with certain entities beyond just single graphic primitives such as lines, dots, characters, etc. Therefore, we may partition the set of all primitives of a picture into equivalence classes with respect to certain common features such as appearance, status, origin, and identifier. Under appearance we subsume controllable features such as the beam intensity (or a graylevel in halftone displays or a color in color displays, etc.) and the line style (in linedrawings). The status determines whether or not an entity is "pickable" by a lightpen or a cursor, whether or not a character string can be overwritten, and whether or not an entity may blink to attract the users attention. Origin is a point in the picture domain to which all other coordinates of an entity are relative. This facilitates the performance of picture transformations. Any such entity is identified by a name, and any member of it represents the whole set with respect to a lightpen pick. A picture structure should, on the other hand, conform with the structure of the language in which the picture-generating programs are written. Two common features of high-level languages can be exploited for the purpose of picture structuring, namely (i) the occurrence of arrays as a primitive data type and (ii) the possibilities of nesting program blocks (albeit not in all languages) and external procedures (subroutines) in connection with the control of the scope of variables. Similar to the subroutine techniques, we furthermore want pictures to be able to invoke subpictures. As a result of these considerations we introduce a general picture structure in the form of a three-level hierarchy as follows:
Unlike regular programs which produce results in the form of a data set obtained by applying a sequence of transformations on an initial set of data, a program for picture generation produces a sequence of instructions whose execution by a special hardware processor results in the generation of a number of graphic primitives in a certain appearance on the CRT screen. Hence, the execution of a display program consists mainly in the process of translating a high-level language program segment into an object language which is interpreted by the special display processor. Therefore, we call the object language display processor code and the object program the display processor code list (DPCL). The object program is strictly sequential except for subpicture jumps. In order to preserve the above introduced picture structure, we may embed the DPCL into a data structure in which each picture is represented by a three-level tree. This is accomplished by adding a name list, containing the names of pictures, subpictures, and items and a correlation table, containing pointers which bound the part of DPCL representing a certain picture, subpicture, or item. The totality of the name list, correlation table, and the display processor code list is called the display file. Thus in the process of translating a display program, we need also routines for updating thename list and the correlation table. Of course, this requires that the programmer designates the entities of his structured pictures to the translator, that is, he must structure his program properly. The display file management is usually performed by the section of the display system which we call the 'display processor' (other names for it are 'display controller' or 'programmable memory'), whereas the data base and the application program reside in a larger computer which we call the 'host computer'. The host may be dedicated to the graphics system, or it may be a time-sharing system in which the display console is one of many terminals. In any case, it is an important design objective to limit the computing power required for the display file management by keeping the data structure of the display file as simple as possible. Therefore, we impose the additional constraint that items shall be partitions of the set of primitives of a picture. Hence, the resulting data structure is that of a tree. By this constraint we deal with trees as the basic display file structure instead of graphs (which are more difficult to handle). Primitives may be categorized as being either graphic primitives or symbols. In the former case the data type is that of real or integer numbers representing coordinates, and in the latter case the data type is that of character codes. To define primitives through their data structure, we have the coordinate point for graphic primitives and the character string for symbols. In general, a point is an n-tuple (n depending on the dimensionality of the picture domain and on whether ordinary or homogeneous coordinates are used) of real or integer numbers (depending on how the picture domain is defined). A dot is the pictorial representation of a point. A vector connects two points. For the sake of consistency and economy, it is customary that a vector be specified only by one point, its end point, whereas its start point is given by the current beam position (which may be the end point of the previously drawn vector). Vectors concatenated in such a way form a polygon, and by providing the possibility of inserting blank (invisible) vectors, any line-drawing can be defined as a polygon. Therefore, a control vector of data type boolean is added, specifying whether a corresponding line is visible or not. In a declaration- free language like APL we can combine the point coordinates and the control vector into one array. In other languages, however, this implies that we restrict ourselves to the use of integer coordinate values. Pictures, subpictures, and items are entities which shall be identified by names. Subpictures shall be defined as entities which are not further divisible. Contrastingly, in the case of items, it is desirable to be able to identify individual primitives in the item. Items, as defined above, are ordered sets; the order being defined by the ordering of the components of the homogeneous array that is assigned as data to the item generating statement.Hence for a set of primitives, P = Pl,.. Pn , there exists a bijective mapping J: P + [1 : n ]. Thus, primitives in an item may be identified by a triple (picture name, item name, ordinal number). in Computer Graphics 9(1) Spring, 1975 - includes Proceedings of the 2nd International Conference on Computer Graphics and Interactive Techniques, 1975, Bowling Green, Ohio view details Historically SKETCHPAD (Sutherland) was the first widely recognized general purpose graphics system. The SKETCHPAD system consists of a collection of subroutines called interactively through a menu selection process. The system allows pictures to be constructed hierarchically from other pictures and is noted for its use of a ring data structure to store picture descriptions. Kulsrud, Williams, and Giloi presented models for the definition of a general purpose graphics language, Kulsrud suggested that the first version of the proposed language have written commands and that it later be adjusted to accept input from graphics devices such as light pens and trackballs. The language she described was capable of picture description, manipulation, and analysis. Although it could be used with interactive applications programs, it was not an interactive language. Williams described a language that provided (i) data types with related operations particularly suited to graphical applications, and (2) the ability to add new data types and operations. For example, a "point,' could be a data type, and a specially defined addition operator would operate on that data type. The language was thus highly extensible, but it was not interactive. Giloi proposed a model to be used in constructing either subroutine packages for graphic display applications or graphical extensions to existing languages. In this model, pictures were described as a hierarchy of subpictures and picture primitives. Primitives were defined as anything for which there was a hardware generator in the display processor, placing limits on the device independence of a language developed from his model. An interactive version of the model was developed by extending APL to include graphics capabilities, and a non-interactive version was developed as a FORTRAN subroutine package. The general purpose graphics systems presented in recent years can be classified as (i) subroutine packages for graphics applications, (2) graphics extensions to existing languages, and (3) new languages possessing graphics capabilities. Graphics subroutine packages are most widely distributed particularly by manufacturers of graphics display hardware. Some example packages are GINO-F, GPGS, GRAF, DISSPLA, and EXPLOR. Most packages are limited to the manipulation of picture displays with few programming control or storage capabilities. Where such abilities are available they often serve specialized purposes as in WAVE, a package for waveform analysis. One exception is the VIP system where the user is able to combine the available system function subroutines into special purpose functions which can then be used in the same way that the original system functions were used. Extensions of an existing language such as Euler-G, IMAGE, APLBAGS, APLG, and PENCIL, provide a programmer with graphics capabilities as well as general programming features. Euler-G has excellent data structure definition facilities. IMAGE, an extension of FORTRAN, cannot provide the data structure description capabilities that are available in Euler-G, but it has the advantage of being based on the most widely distributed host language available. APLBAGS, APLG, and PENCIL, an extension of the MULTILANG on-line programming system, are truly conversational languages. GRASP, a PL/I extension, is a compiled language but it allows dynamic interaction. GRASP also allows the definition of models from which complex pictures can be created hierarchically. ESP3, an extension of SNOBOL4, is a non-interactive language from which many of the high-level concepts found in PIGLI are drawn. Language extensions are found mainly in experimental installations. Two complete graphics languages are METAVISU and GLIDE. Both take characteristics from a base language (PL/I and ALGOL, respectively) and add capabilities for defining, displaying, and manipulating pictures. Full languages are less widely distributed than subroutine packages or language extensions. in Proceedings of the 1978 annual conference 1978, Washington, D.C., United States view details |