Movatterモバイル変換

Network Working Group                                            D. HuffRequest for Comments: 285                                    CWRU (Case)NIC: 8271                                              December 15, 1971Updates:        NoneObsoletes:      NoneNetwork Graphics        Not much has been written about graphics on the ARPANET when thevolume of the NIC collection is considered. Presently it contains some8000 entries of which only about 20 are on the subject of graphics. Thereason is probably similar to that given by L. G. Roberts in A FORWARDLOOK (NIC 7542) as the reason that data base sharing or software sharingwill not be important topics for several more years: the NET hasn't beenup long enough for interested people to have enough of the facts to knowif it is feasible and to think creatively.        This paper is therefore aimed at bringing together the presentstate of graphics on the NET for the newcomer and attempting to add alittle more distance to the ground covered so far. I will start with anoverview, then proceed to briefly describe past work, and finally addsome of my own thoughts.        Since the NET represents a wealth of data processors, any or allof which may be used at one time, we are not restricted to theconfigurations most generally found in private installations where thereis a main processor and a somewhat less capable machine or perhaps noneat all doing the honors as display processor. Indeed when using the NETit might occur that one has a more powerful machine as the displayprocessor than the machine which is running the main job. Graphics onthe NET need not be anything like what we know it as now.        There is of course a greater more diversified mix of graphicsequipment that must be considered when designing a standard graphicslanguage and its processor. If we wish to drive an aribitrary displayfrom a program such an output language must be quite general, but theprocessor which constructs the actual display list for the targetdisplay need not and in fact will not be general, rather its only jobwill be to translate a well defined general language to meet therequirements of one specific graphics terminal.        Attention handling, a lately discussed and much worried abouttopic, presents an entirely different problem. This time the NET maycause more harm than good for the simple reason that now there may beseveral, instead of one (in some cases none at all), mappings defined toget from the initial display list that the main job process is creating                                   1RFC 285  NIC 8271to the final display list which interactive devices such as the lightpen actually refer to. This is a problem which has to be faced and hasbeen solved at many different sites in as many different ways. It islikely to give as much trouble as the final concept.        Local processing is in many cases a very simple thing toaccomplish when the display terminal is "intelligent" or even has itsown medium or large scale processor which has little or nothing else todo aside from refreshing the display. Such processing can be simpleadditions or deletions to the picture which certainly do not require themain job process to accomplish. The local processor need only notify themain process of what changes have been made to the display list so thatthe main copy may be updated. The allocation of abilities poses the lastproblem. The lower limit is reached when the local processor is unableto do anything beyond keeping the picture displayed, and the upper limitapplies to the case when the local processor is more powerful than themain processor and handles all attentions itself. Now such questions as,just which copy of the display list is the master copy, who isresponsible for seeing that all copies of the list contain the sameinformation, and what kind of mappings between display lists arerequired, become the important ones we all seek to answer.        Proposals for Network Standard Graphics started with the idea ofa simple interpretable language containing only commands to erase thescreen, display a string of text, move the beam or draw a line or pointwithin a virtual rectangle which is the generalized display screen,execute a previously defined subroutine, and replace the contents of asubroutine with what follows in the command stream. Movements within thescreen area were defined in terms of fractions of the screen dimensionsinstead of absolute lengths. This proposal was responded to with thesuggestion that a graphics standard could not be so restrictive and findwide acceptance. The proposal was not expressive enough to handlesophisticated picture manipulations. It was recognized that a standardmust be able to make use of all graphics hardware, present and withinthe forseeable future. The data structure should represent both logicaland pictorial structure, allow for the definition and manipulation ofsubpictures, and division of the display screen into logical units. Theproposed standard has now become a general high-level language ratherthan a low-level language. It was pointed out that all sites need not beable to handle the interpretation of this graphic language, but becauseof the existence of the rest of the NET, one of the other machines couldrun the interpreter, this is equivalent to a data reconfigurationservice. Such drawing modes as intensity, blinking, dashed, color, orstereo should also be expressable by means of a command to set the mode.The canonical definition of a character string should be defined sinceeveryone has their own way of displaying text and most of them are                                   2RFC 285  NIC 8271different. It is suggested that the Multics convention be used asdescribed by Osanna, J., Sahzer, J., Remote Terminal Character StreamProcessing of Multics, Proceedings SJCC, 1970,  p. 671.        If in addition to simply displaying graphic information, if onewishes to to interact with the picture directly, the protocol mustinclude a standard for feedback, attention handling as it is beingcalled. Attentions may not always refer directly to the picture however,as in the case of keyboard input which can be handled as any otherstandard message on the NET. Some graphics processors may also have thecapability of handling attentions locally and only need to report theend result to the main process. This is the problem of which datastructure is most up to date, which is considered the master copy, andhow can the processes be kept in sync? The observation is also made thatas long as the graphics application program, the main process,communicates with a pair of graphic device handling routines in anetwork standard language, the system configuration can be arbitrary andany terminal may be attached to any main process. The same is of coursetrue of attention handling, a set of standards for the transmission ofan attention generated by a particular device when developed will allowany graphics terminal to be understood by any other main process. Asummary of input devices has been given along with typical outputs andthe suggestion that each attention message identify the device causingthe attention, the data which is being supplied, and of course, the dataitself.        The proposed graphic protocol has become much richer in displaytypes. The following list was suggested as basic: points, lines,vectors, character strings, viewport and window, transformations ofinstances, hardware-dependent byte streams, attention commands. Thepoint was also made that special considerations for grey-scale devicesare needed and four alternate display modes are discussed (NIC 7128).        An example of hardware sharing is described in NIC 7130. It is aprotocol for the use of the LDS-1 processor at M.I.T. by anyone on thenet who has a program for the LDS-1. This Graphics Loader, as it iscalled, provides for the execution of programs that have been sent tothe PDP-10 at M.I.T. and the return of the data generated when theprogram is executed. The picture is not drawn on a display, but sincethe LDS-1 processor can be instructed as to what to do with thecoordinates that it generates, the Graphics Loader sets up the processorto write back into core the computed display coordinates. Thesecoordinates may now be sent back to the originating site for display oras a debugging aid.                                   3RFC 285  NIC 8271        In NIC 7137 many of these previously discussed points are againbrought up, but this time under the supposition that a graphics terminalshould be just another terminal with minimal special privileges.Suggestions were also made pertaining to the design of a graphicsprotocol with particular emphasis on display structure, attentionhandling, coordinate systems, and the difference between storage tubeand refreshed display requirements.        A specific solution for the handling of tablet input data hasbeen presented, (NIC 7151), along with the expression that the graphicsprotocol should be designed so that non-interactive graphics should notbe complicated with the requirements imposed by the interactive aspectsof the protocol. It is pointed out that there are several types oftablet data that can be sent as input to a graphics process. Four typesof data are described. They are single-shot, raw asynchronous, rawsynchronous, and preprocessed data. Preprocessed data can be smoothed orfiltered or thinned using various techniques to make the data moreuniform and workable. Velocities can also be calculated for each pointto aid in the interpretation of the data.        The description of NETCRT (NIC 7172) is the first encounter withlocal processing, or lack of it. NETCRT is a protocol between a centralprocessor and a character display. The character display is completelyslaved to the central processor and can do no local processing, howeverit can interrupt the processor thus signalling that the user is donetyping 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 Isummarized them because I don't think that it would have been in linewith what I am trying to do in this paper. I think that there is a needto consider an overall model of the graphic system we are trying todesign. Previous proposals have dealt with some set of details withoutidentifying with a general model, producing good ideas forimplementation of details but not considering how the whole will fittogether. Thus I would like to propose a model for our graphics system.It will contain many protocols and leave many areas to be discussedfurther, but it will provide a starting point from which work can bedone along simple lines, and yet not exclude the later inclusion of moresophisticated abilities.        Figure 1 shows a block diagram of information flow. The PROCESSindicates a graphics application program which is running on a computerin the net. Its associated INPUT and OUTPUT routines can be thought ofas being a set of subroutines loaded with the main PROCESS or asseparate and running elsewhere serving many users. At the other end ofthe loop are a set of INPUT and OUTPUT drivers for the DISPLAY which isbeing used to display the graphics information. The information flowing                                   4RFC 285  NIC 8271from the PROCESS to the DISPLAY is drawing information for the buildingand manipulation of pictures. The information flowing from the DISPLAYto the PROCESS is attention information. The Graphic Data Baseassociated with the main PROCESS is that which is constructed when thepicture is being drawn by the PROCESS or when the picture is being drawnby local processing and attention messages tell the PROCESS what hasbeen done to the picture. This data base need not contain moreinformation that the PROCESS is willing to work with, and in fact neednot contain anything if no picture interaction is to be done. TheGraphic Data Base associated with the DISPLAY drivers is built bythemselves so that the OUTPUT driver can handle attentions from theDISPLAY without requiring the main PROCESS to be able to do this and forthe INPUT driver to use when modifying the picture based on what isactually being displayed. The information flowing to and from the mainPROCESS is the sort which is passed or received as parameters toprocedures. The INPUT and OUTPUT routines translate to and fromrespectively a network standard graphics protocol which is sent out overthe net to the INPUT and OUTPUT display drivers whose responsibility itis to translate the standard message into the appropriate byte stream todrive the DISPLAY or translate the attention from the DISPLAY into anetwork standard message. The DISPLAY is assumed to handle its ownrefreshing if it requires any, so that there will be as little apparentdifference between refreshed and non-refreshed displays as is possible.        This model provides for both simplicity of use for those doingsimple things and power which is needed for those doing sophisticatedinteractive graphics. It can be used with a minimum of effort andoverhead by setting runtime conditions to indicate that no interactivegraphics will be done and all associated processing should be skipped,while still enabling other PROCESSes to do high powered graphics withoutgoing to a completely different set of routines and rules.        Due to the existence of two separate data bases, which must bekept up-to-date with each other there are two modes of operating thismodel. For lack of better names let us call them PROGRAM graphics andLOCAL graphics. The former indicates that the picture being displayed isconstructed by the main PROCESS and all input from the user at thedisplay is solicited, thus the DISPLAY data base is only updated afterand as a result of action by the main PROCESS. The latter indicates thatthe user at the display is directing the construction of a picture bymeans of function buttons and drawing tools, the DISPLAY data base isupdated immediately and the main PROCESS is notified of the change sothat it may keep up, but it does not perform manipulations of thepicture unless requested to do so by the DISPLAY OUTPUT driver; this canbe as a result of a request to perform some function that the DISPLAYINPUT/OUTPUT drivers can do by themselves or a request by the user tohave the main PROCESS perform a non-standard function on the picture.                                   5RFC 285  NIC 8271        The main purpose of this design is to allow greatest generalityof graphic configurations rather than minimum response time. The designfor an optimum requires more exact specification of the hardwareconfiguration and the proposed usage. Since neither of these variablescan be known, and in fact our attempt at generality keeps us from evenguessing very closely at them, we must provide intelligent INPUT/OUTPUTdrivers that will know how to split the processing load betweenthemselves and the main PROCESS as a function of what kind of DISPLAYthey are driving, rather than attempting to design in an optimumbreakpoint.        The Graphics Protocol should specify the format of the messageswhich are transmitted between the INPUT and OUTPUT routines and drivers.These messages can be divided as previously mentioned according to theirdirection and content, i.e. drawing messages and attention messages.Since it is often desired to intermix graphics and text there should bea distinguishing message header for all graphics messages. Then a byteto 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. Virtuallyall of the necessary message types have been indicated in the previousRFCs and I will not list them here, except to note that attentions nowinclude requests for processing that the drivers could not do.        To summarize, I believe that a simple model is enough to enablethe design of both sophisticated interactive graphics and low effortnon-interactive graphics. The primary reason for this is that our majorinterest is not minimum response, but rather maximum configurationmixes. There are opportunities to use software sharing and datareconfiguration services when building INPUT/OUTPUT routines anddrivers. Much detailed work remains to be done, but with a basic modelin sight providing a framework to hang proposed ideas on for evaluation,work should be able to proceed more smoothly.                                   6RFC 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