diff options
Diffstat (limited to 'doc/rfc/rfc285.txt')
| -rw-r--r-- | doc/rfc/rfc285.txt | 420 |
1 files changed, 420 insertions, 0 deletions
diff --git a/doc/rfc/rfc285.txt b/doc/rfc/rfc285.txt new file mode 100644 index 0000000..7c5a27e --- /dev/null +++ b/doc/rfc/rfc285.txt @@ -0,0 +1,420 @@ + + + + + + +Network Working Group D. Huff +Request for Comments: 285 CWRU (Case) +NIC: 8271 December 15, 1971 +Updates: None +Obsoletes: None + + + Network Graphics + + + Not much has been written about graphics on the ARPANET when the +volume of the NIC collection is considered. Presently it contains some +8000 entries of which only about 20 are on the subject of graphics. The +reason is probably similar to that given by L. G. Roberts in A FORWARD +LOOK (NIC 7542) as the reason that data base sharing or software sharing +will not be important topics for several more years: the NET hasn't been +up long enough for interested people to have enough of the facts to know +if it is feasible and to think creatively. + + This paper is therefore aimed at bringing together the present +state of graphics on the NET for the newcomer and attempting to add a +little more distance to the ground covered so far. I will start with an +overview, then proceed to briefly describe past work, and finally add +some of my own thoughts. + + Since the NET represents a wealth of data processors, any or all +of which may be used at one time, we are not restricted to the +configurations most generally found in private installations where there +is a main processor and a somewhat less capable machine or perhaps none +at all doing the honors as display processor. Indeed when using the NET +it might occur that one has a more powerful machine as the display +processor than the machine which is running the main job. Graphics on +the NET need not be anything like what we know it as now. + + There is of course a greater more diversified mix of graphics +equipment that must be considered when designing a standard graphics +language and its processor. If we wish to drive an aribitrary display +from a program such an output language must be quite general, but the +processor which constructs the actual display list for the target +display need not and in fact will not be general, rather its only job +will be to translate a well defined general language to meet the +requirements of one specific graphics terminal. + + Attention handling, a lately discussed and much worried about +topic, presents an entirely different problem. This time the NET may +cause more harm than good for the simple reason that now there may be +several, instead of one (in some cases none at all), mappings defined to +get from the initial display list that the main job process is creating + + + + 1 + + + + + +RFC 285 NIC 8271 + + +to the final display list which interactive devices such as the light +pen actually refer to. This is a problem which has to be faced and has +been solved at many different sites in as many different ways. It is +likely to give as much trouble as the final concept. + + Local processing is in many cases a very simple thing to +accomplish when the display terminal is "intelligent" or even has its +own medium or large scale processor which has little or nothing else to +do aside from refreshing the display. Such processing can be simple +additions or deletions to the picture which certainly do not require the +main job process to accomplish. The local processor need only notify the +main process of what changes have been made to the display list so that +the main copy may be updated. The allocation of abilities poses the last +problem. The lower limit is reached when the local processor is unable +to do anything beyond keeping the picture displayed, and the upper limit +applies to the case when the local processor is more powerful than the +main processor and handles all attentions itself. Now such questions as, +just which copy of the display list is the master copy, who is +responsible for seeing that all copies of the list contain the same +information, and what kind of mappings between display lists are +required, become the important ones we all seek to answer. + + Proposals for Network Standard Graphics started with the idea of +a simple interpretable language containing only commands to erase the +screen, display a string of text, move the beam or draw a line or point +within a virtual rectangle which is the generalized display screen, +execute a previously defined subroutine, and replace the contents of a +subroutine with what follows in the command stream. Movements within the +screen area were defined in terms of fractions of the screen dimensions +instead of absolute lengths. This proposal was responded to with the +suggestion that a graphics standard could not be so restrictive and find +wide acceptance. The proposal was not expressive enough to handle +sophisticated picture manipulations. It was recognized that a standard +must be able to make use of all graphics hardware, present and within +the forseeable future. The data structure should represent both logical +and pictorial structure, allow for the definition and manipulation of +subpictures, and division of the display screen into logical units. The +proposed standard has now become a general high-level language rather +than a low-level language. It was pointed out that all sites need not be +able to handle the interpretation of this graphic language, but because +of the existence of the rest of the NET, one of the other machines could +run the interpreter, this is equivalent to a data reconfiguration +service. Such drawing modes as intensity, blinking, dashed, color, or +stereo should also be expressable by means of a command to set the mode. +The canonical definition of a character string should be defined since +everyone has their own way of displaying text and most of them are + + + + + + 2 + + + + + +RFC 285 NIC 8271 + + +different. It is suggested that the Multics convention be used as +described by Osanna, J., Sahzer, J., Remote Terminal Character Stream +Processing of Multics, Proceedings SJCC, 1970, p. 671. + + If in addition to simply displaying graphic information, if one +wishes to to interact with the picture directly, the protocol must +include a standard for feedback, attention handling as it is being +called. Attentions may not always refer directly to the picture however, +as in the case of keyboard input which can be handled as any other +standard message on the NET. Some graphics processors may also have the +capability of handling attentions locally and only need to report the +end result to the main process. This is the problem of which data +structure is most up to date, which is considered the master copy, and +how can the processes be kept in sync? The observation is also made that +as long as the graphics application program, the main process, +communicates with a pair of graphic device handling routines in a +network standard language, the system configuration can be arbitrary and +any terminal may be attached to any main process. The same is of course +true of attention handling, a set of standards for the transmission of +an attention generated by a particular device when developed will allow +any graphics terminal to be understood by any other main process. A +summary of input devices has been given along with typical outputs and +the suggestion that each attention message identify the device causing +the attention, the data which is being supplied, and of course, the data +itself. + + The proposed graphic protocol has become much richer in display +types. The following list was suggested as basic: points, lines, +vectors, character strings, viewport and window, transformations of +instances, hardware-dependent byte streams, attention commands. The +point was also made that special considerations for grey-scale devices +are needed and four alternate display modes are discussed (NIC 7128). + + An example of hardware sharing is described in NIC 7130. It is a +protocol for the use of the LDS-1 processor at M.I.T. by anyone on the +net who has a program for the LDS-1. This Graphics Loader, as it is +called, provides for the execution of programs that have been sent to +the PDP-10 at M.I.T. and the return of the data generated when the +program is executed. The picture is not drawn on a display, but since +the LDS-1 processor can be instructed as to what to do with the +coordinates that it generates, the Graphics Loader sets up the processor +to write back into core the computed display coordinates. These +coordinates may now be sent back to the originating site for display or +as a debugging aid. + + + + + + + + 3 + + + + + +RFC 285 NIC 8271 + + + In NIC 7137 many of these previously discussed points are again +brought up, but this time under the supposition that a graphics terminal +should be just another terminal with minimal special privileges. +Suggestions were also made pertaining to the design of a graphics +protocol with particular emphasis on display structure, attention +handling, coordinate systems, and the difference between storage tube +and refreshed display requirements. + + A specific solution for the handling of tablet input data has +been presented, (NIC 7151), along with the expression that the graphics +protocol should be designed so that non-interactive graphics should not +be complicated with the requirements imposed by the interactive aspects +of the protocol. It is pointed out that there are several types of +tablet data that can be sent as input to a graphics process. Four types +of data are described. They are single-shot, raw asynchronous, raw +synchronous, and preprocessed data. Preprocessed data can be smoothed or +filtered or thinned using various techniques to make the data more +uniform and workable. Velocities can also be calculated for each point +to aid in the interpretation of the data. + + The description of NETCRT (NIC 7172) is the first encounter with +local processing, or lack of it. NETCRT is a protocol between a central +processor and a character display. The character display is completely +slaved to the central processor and can do no local processing, however +it can interrupt the processor thus signalling that the user is done +typing or wishes to begin typing. NETCRT tries to maintain good man- +machine interaction by controlling the state of the terminal. + + I have refrained from commenting on the various proposals as I +summarized them because I don't think that it would have been in line +with what I am trying to do in this paper. I think that there is a need +to consider an overall model of the graphic system we are trying to +design. Previous proposals have dealt with some set of details without +identifying with a general model, producing good ideas for +implementation of details but not considering how the whole will fit +together. Thus I would like to propose a model for our graphics system. +It will contain many protocols and leave many areas to be discussed +further, but it will provide a starting point from which work can be +done along simple lines, and yet not exclude the later inclusion of more +sophisticated abilities. + + Figure 1 shows a block diagram of information flow. The PROCESS +indicates a graphics application program which is running on a computer +in the net. Its associated INPUT and OUTPUT routines can be thought of +as being a set of subroutines loaded with the main PROCESS or as +separate and running elsewhere serving many users. At the other end of +the loop are a set of INPUT and OUTPUT drivers for the DISPLAY which is +being used to display the graphics information. The information flowing + + + + 4 + + + + + +RFC 285 NIC 8271 + + +from the PROCESS to the DISPLAY is drawing information for the building +and manipulation of pictures. The information flowing from the DISPLAY +to the PROCESS is attention information. The Graphic Data Base +associated with the main PROCESS is that which is constructed when the +picture is being drawn by the PROCESS or when the picture is being drawn +by local processing and attention messages tell the PROCESS what has +been done to the picture. This data base need not contain more +information that the PROCESS is willing to work with, and in fact need +not contain anything if no picture interaction is to be done. The +Graphic Data Base associated with the DISPLAY drivers is built by +themselves so that the OUTPUT driver can handle attentions from the +DISPLAY without requiring the main PROCESS to be able to do this and for +the INPUT driver to use when modifying the picture based on what is +actually being displayed. The information flowing to and from the main +PROCESS is the sort which is passed or received as parameters to +procedures. The INPUT and OUTPUT routines translate to and from +respectively a network standard graphics protocol which is sent out over +the net to the INPUT and OUTPUT display drivers whose responsibility it +is to translate the standard message into the appropriate byte stream to +drive the DISPLAY or translate the attention from the DISPLAY into a +network standard message. The DISPLAY is assumed to handle its own +refreshing if it requires any, so that there will be as little apparent +difference between refreshed and non-refreshed displays as is possible. + + This model provides for both simplicity of use for those doing +simple things and power which is needed for those doing sophisticated +interactive graphics. It can be used with a minimum of effort and +overhead by setting runtime conditions to indicate that no interactive +graphics will be done and all associated processing should be skipped, +while still enabling other PROCESSes to do high powered graphics without +going to a completely different set of routines and rules. + + Due to the existence of two separate data bases, which must be +kept up-to-date with each other there are two modes of operating this +model. For lack of better names let us call them PROGRAM graphics and +LOCAL graphics. The former indicates that the picture being displayed is +constructed by the main PROCESS and all input from the user at the +display is solicited, thus the DISPLAY data base is only updated after +and as a result of action by the main PROCESS. The latter indicates that +the user at the display is directing the construction of a picture by +means of function buttons and drawing tools, the DISPLAY data base is +updated immediately and the main PROCESS is notified of the change so +that it may keep up, but it does not perform manipulations of the +picture unless requested to do so by the DISPLAY OUTPUT driver; this can +be as a result of a request to perform some function that the DISPLAY +INPUT/OUTPUT drivers can do by themselves or a request by the user to +have the main PROCESS perform a non-standard function on the picture. + + + + + 5 + + + + + +RFC 285 NIC 8271 + + + The main purpose of this design is to allow greatest generality +of graphic configurations rather than minimum response time. The design +for an optimum requires more exact specification of the hardware +configuration and the proposed usage. Since neither of these variables +can be known, and in fact our attempt at generality keeps us from even +guessing very closely at them, we must provide intelligent INPUT/OUTPUT +drivers that will know how to split the processing load between +themselves and the main PROCESS as a function of what kind of DISPLAY +they are driving, rather than attempting to design in an optimum +breakpoint. + + The Graphics Protocol should specify the format of the messages +which are transmitted between the INPUT and OUTPUT routines and drivers. +These messages can be divided as previously mentioned according to their +direction and content, i.e. drawing messages and attention messages. +Since it is often desired to intermix graphics and text there should be +a distinguishing message header for all graphics messages. Then a byte +to specify the type of information contained in the body of the message, +a count of the bytes in the body, and finally the body itself. Virtually +all of the necessary message types have been indicated in the previous +RFCs and I will not list them here, except to note that attentions now +include requests for processing that the drivers could not do. + + To summarize, I believe that a simple model is enough to enable +the design of both sophisticated interactive graphics and low effort +non-interactive graphics. The primary reason for this is that our major +interest is not minimum response, but rather maximum configuration +mixes. There are opportunities to use software sharing and data +reconfiguration services when building INPUT/OUTPUT routines and +drivers. Much detailed work remains to be done, but with a basic model +in sight providing a framework to hang proposed ideas on for evaluation, +work should be able to proceed more smoothly. + + + + + + + + + + + + + + + + + + + + 6 + + + + + +RFC 285 NIC 8271 + + + +---------+ +--------+ + ! INPUT ! ! OUTPUT ! + +--! routine !<------||---------! driver !<--+ + ! +---------+ +--------+ ! + ! ^ ! + V ! ! + +---------+---------+ +---------+ ! +---------+ + ! ! Graphic ! ! Graphic ! ! ! ! + ! PROCESS ! Data ! ! Data !<->! ! DISPLAY ! + ! ! Base ! ! Base ! ! ! ! + +---------+---------+ +---------+ ! +---------+ + ! ! ^ + ! V ! + ! +---------+ +--------+ ! + ! ! OUTPUT ! ! INPUT ! ! + +->! routine !-------||-------->! driver !---+ + +---------+ +--------+ + + Figure 1 + + + + + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Ian Redfern 4/99 ] + + + + + + + + + + + + + + + + + + + + + + + + 7 + + |