Movatterモバイル変換

Network Working Group                                        Steve BunchRFC # 472                                                    ILL-ANTSNIC # 14801                                                  March, 1973Illinois' reply to Maxwell's Request for Graphics Information,NIC Document 14925.This is a reply to Craig Maxwell's (UCLA-NMC) "Request for graphicsinformation" of 3/7/73.  Further details can be obtained by contactingme directly.To date, our work in graphics has been primarily centered about supportfor several applications groups.  To make the generation of beam-oriented graphics as painless as possible for these groups, our policyfor supporting this type of graphics has been to emulate as closely aspossible the CALCOMP plotter support package on the host machine, butwith NGP0 output.  (Presently, before the resulting NGP can be sent tosome of our peripherals, e.g., Gould 4800, it must be converted todevice specifics.  With the advent of ANTS MARK II and a PDP-11/45, allconversions will be handled locally, so all graphics flowing into oursystem will be NGP).  We find this approach very labor-saving, even atthe present slightly kludgey level.We also have some grey-scale work taking place on our GOULD and IMLAC.One group is processing satellite pictures on Illiac and will soon needgrey-scale output, another is producing natural-resource maps, and athird is generating holograms.  No standardization plans have been madefor grey scale work, but if an acceptable standard is established, wewill most likely use it.A small group, including myself, is currently planning an interactivegraphics system.  The system will use multiple hosts, possibly using aremote E&S machine for rotation, scaling, etc.  We have a number oflarge hurdles that have to be jumped before we can do anything, though.Several of these are not graphics-specific, such as process-controlledFTP, inter-process coordination among hosts, and others.  We hadintended to let efficiency dictate the format of intermediate resultsshipped via the Net, with standardization being applied where it ishelpful for minimizing effort.  Since the system will be highlyinteractive and will also manipulate grey-scale data, we will need ahigher level of graphics protocol to handle the user interface.  A"proto-prototype" system is being used now to do some simplemanipulations of meteorological data (e.g., contouring, 3-D plotting)Bunch                                                           [Page 1]

RFC 472        Reply to Request for Graphics Information      March 1973with an IMLAC passively displaying the NGP0 pictures created.  Soon, Ihope to finish an IMLAC program that will handle some interaction withthe mouse/keyset.  I have decided to implement the following (outgoing)commands.    MOVE  beam to mouse position    DRAW  from last to present beam position.    TEXT  at present beam position.    UNDO  the last command (to facilitate freehand drawing and          backspacing in TEXT).Other commands may be implemented as needed to do what people want todo, at least until an adequate interaction standard comes along.Note that there is implicit in the UNDO command the assumption thatthe other end of the line possesses a certain amount of memory andintelligence.  Two possible philosophies for standardizing interactionare that (1) all "nodes" ("generators" or "users" of data) understandsome set of commands and possess at least a certain amount ofintelligence, and (2) a distinction is made between "displays" and"computers" (quotes because the line is fuzzy).  I favor the first forits generality, but I suggest that the lowest level of interactivegraphics might want to use the second for ease of implementation withunintelligent devices, e.g., COMPUTEK 400's.  (I do not mean toimply in (1) that the actual "computer" would not have a largervocabulary than the actual "display" --this is inevitable with higherlevel capabilities in the protocol).Since we have almost no local computing power for applications work,all our graphics computation is done remotely (our work has beenprimarily at UCSD (B6700), USC-ISI (TENEX), and UCLA-CCN (360)).Because we do our work at scattered sites and are basically economicof labor (pronounced "lazy"), we have a lot to gain by standards andwill be glad to cooperate as much as possible with standardizationefforts.Steve Bunch       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by Alex McKenzie with    ]       [ support from GTE, formerly BBN Corp.             9/99 ]Bunch                                                           [Page 2]