An overriding goal in designing a graphics language (be it a set of subroutines or an extension to an existing language) is that the language be convenient and natural for the user of the language (that is, the application programmer). At the same time, the language must be powerful and should utilize all the capabilities of the often very expensive display hardware. With these goals in mind, it is a formidable task to develop a uniform standard for a language to meet diverse application needs and to operate with hardware of widely differing capabilities.
The problem I wish to address arises in interactive plotting and drawing applications, wherein the picture creation process is conceptually different from and inherently less complex than the picture modification process. I do believe that standards for picture creation can be arrived at and be made acceptable to a diverse collection of users and manufacturers. I am less confident about standards for picture modification.
Picture modification usually brings to mind transformations like rotate, translate, shear, scale, and perspective. These important features have been given much attention in the literature. However, I wish to focus on features which are usually considered solely part of the picture creation process, but which, in many computer-assisted instruction and computer-aided design applications, are a significant portion of the picture modification process. These features are often grouped under the terms picture attributes or screen attributes. A list of such attributes for the Vector General 3D3 Display System include:
Values for these attributes are usually found by the display processing unit encoded in fixed positions in the constituent words of the display list or in special hardware registers. Most general purpose graphics languages like GPGS and GINO-F permit one to assign values to these attributes, but only prior to picture compilations.
For example, to change the style of a line from solid to dotted requires the deletion of that line, a change made to the line style value, and a recreation of the same line. If that line is a constituent part of a larger structure which is otherwise manipulated as a whole, such a sequence of operations is extremely wasteful of both the CPU's and the application programmer's time and attention. How much more economical, in theory at least, to locate the offending element (usually a single word in the display list) and modify it directly with the correct bit pattern. In fact, most graphics languages do recognize the importance of this; consequently their visibility and light pen sensitivity attribute commands usually operate on previously created picture segments. To allow other attributes to be changed within a picture definition requires that a location mechanism be implemented for them. Then one would either do a direct, in place, overwrite of the display code or do a delete followed by the extend picture segment operation found in most high level languages.
Some existing languages do permit such operation: simply make every object to be changed a picture segment. But this extracts a high price. The overhead associated with a picture segment is often large, usually including a 4 × 4 window-to-viewport transformation matrix. On the one hand, if there are one hundred lines to be manipulated, all using the same window-to-viewport transformation, then specifying each line as a picture segment costs extra storage for 99 times 4×4 real variables. On the other hand, putting all the lines in a single segment forces a recompilation of the complete 100 line picture segment by the picture compiler each time a line is modified. For some applications, then, it would seem desirable to permit delete and change operations to be performed on any named element, including picture primitives, not just on picture segments.
To accommodate this in a language standard, there are several approaches. One could define modification for a certain graphical data structure level. All changes below that level would require recreation of the picture. Another approach would specify several levels of modification but only the highest level of function might be made mandatory for inclusion in the standard. If a graphics package did choose to supply multiple levels of capability, at least the syntax and semantics for each level would be standardized upon. A third approach might ignore graphical data structure completely. Only primitive elements could be modified. The user would then be responsible for all higher level organization of his picture primitives. All these alternatives are unsatisfactory in certain cases - unsatisfactory, I claim, because they deal with the application programmer interface.
This raises a most fundamental issue which should be addressed at the Workshop. Namely, do we wish to develop a standard, high level graphics language thus directly permitting the portability of application programs or do we wish to develop a standard, device-independent meta-language in which graphics languages would be written, thus directly providing portability of language and indirectly permitting portability of programs?
I favor the latter goal because it favors the development of specialized languages to serve specialized classes of users. It also favors the introduction of new and better hardware, since one could always rewrite the meta-language implementation to provide access to the hardware newly made available without impacting previous implementations on which several languages might be based. Finally, with the programmer's needs and the manufacturer's needs more or less satisfied, as new functions like shaded surfaces or splines were seen to have wide applicability and a close connection to state of the art hardware, they could be incorporated into the meta-language as primitives and be standardized upon in a gradual, incremental manner, without impact on existing languages and thus existing application programs.
The initial discussion about picture modification is seen, then, to be somewhat of a deception. A real user problem and attempted solutions were discussed in order to show the pitfalls which one encounters when trying to standardize at the application programmer interface. That is why GINO-F, GPGS, DISSPLA, and a myriad of other excellent high-level packages should never be proposed as a standard. It is more realistic to develop a language for GPGS, GINO-F, and others to be written in by graphics language implementers - a much smaller collection of people, more skilled and homogeneous than the set of application programmers, it is more productive to have manufacturers of display hardware focus their resources on improving the performance of their hardware and on the implementation of a single standard graphics language never directly programmed in by most of their users, rather than on the generally incomplete collection of subroutines which they generously call a language. It is also more productive for application programmers to focus on developing useful programs rather than on learning to cope with the limitations of a general purpose graphics language which meets no one's needs very well.
