rfc184.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        Karl Kelley
Request for Comments 184                          University of Illinois
NIC 7128                                                     6 July 1971
Category:  D.6


                     Proposed Graphic Display Modes

   The ARPA Network node at the University of Illinois' Center for
   Advanced Computation is somewhat different from other nodes in that
   we are not simply attaching an existing computer center to the net.
   We are in the process of establishing the computer system
   specifically for use of the ILLIAC IV and the Network.  In this mode
   we are establishing operating systems, network interface and utility
   routines, and ILLIAC IV routines to be used over the network.

   In the field of computer graphics we are in the process of building a
   system essentially from scratch.  The building blocks of this
   capability comprise a small -- but growing -- collection of display
   hardware and a small cadre of persons with experience on separate and
   unique graphics equipment at the University of Illinois.  Starting as
   we are with little-or-no system type software for computer graphics,
   we have a once-only opportunity to provide the system with computer
   graphics applications and utility programs which encompass all the
   features and capabilities that have heretofore been available only in
   bits and pieces at various separate installations.

   It is apparent at the outset that the design for this system will be
   heavily weighted toward a network-type usage.  For this reason we are
   eager to ensure that our system data structures, files, etc., be as
   nearly compatible the Network Graphics Protocol as is practicable.
   Our initial planning and first-version system will be pointed at the
   network type of operation and we hope to stay flexible enough to
   employ the Network Protocol on a local basis (between our PDP-11 and
   the B6500) as the protocol is developed.

   We have been considering (in the planning of our system and pondering
   the protocol problem) just what display modes we would want to have
   available and thus would want the protocol to include.  The purpose
   of this RFC is to outline our initial thoughts on the matter and to
   interact with other nodes about how they can/should be included in
   the protocol.  We intend here not to belabor display modes which are
   certain to be needed everywhere, such as vectors, points, and
   characters, but rather to summarize those and outline in more detail
   only those which are slightly different.






Kelley                                                          [Page 1]

RFC 184              Proposed Graphic Display Modes          6 July 1971


   The display system, and the network protocol, will require something
   like the following list of display types:

                                         /
   1. Points                            | Including normal points,
                                       <  plot a symbol at a point, plot
                                        | a point with intensity
                                        \

                                        /
   2. Lines(two-point)                  | These two (2 and 3) include
                                       <  visible and not visible, dotted,
   3. Vectors (from present beam        | dashed, overbright, and ?
               location to a point)     \

   4. Character Streams

   5. Viewport and Window
      Specifications (ala LDS-1)

   6. Transformations (scaling and
      rotation) of Instances

   7. Equipment-Specific Byte Streams

   8. Read-Back of Keyboards,
      Function Buttons, Cursors, Etc.

   It seems clear that some type of list or ring structure will be
   needed to handle our display files.  Whether that structure need be a
   part of the protocol is not evident (after all, you could just send
   the equipment byte-stream), but it is our feeling that it will be
   needed.  It is evident that the protocol must anticipate the needs of
   various popular display devices as CalComp, Computek, and similar
   storage displays, interactive displays such as Adage, LDS-1, Vector
   General, IDIOM, grey-level displays like the PEP-1 and raster-
   oriented gadgets like the Gould, Versatec, and garden-variety line
   printers.

   The standard display element types given above are assumed to be in
   common use.  A point, for example, is a pen-down command followed by
   a pen-up command on a plotter.  On an interactive device it is merely
   an intensification of the beam.  To plot a symbol at a point the pen
   (beam) is moved to the point with pen up (beam off) and then the
   symbol is plotted incrementally with the pen down (beam on).
   Graphics devices with beam intensity control will be expected to
   handle the "plot-point-with-intensity" format.




Kelley                                                          [Page 2]

RFC 184              Proposed Graphic Display Modes          6 July 1971


   In terms of the standard display types the only difference between
   lines of the two-point form and vectors is that in the former, four
   data items are needed for each segment while in the latter, only two
   data items are needed.  In either case, the user should be able to
   reposition the pen (beam) absolutely by drawing an invisible line.
   He should also be able to plot dotted or dashed lines without having
   to separately specify each point or short vector.  In instances where
   emphasis is needed it is useful to be able to selectively intensify a
   line, or in the case of interactive displays, make it blink.

   Character streams are used either for text or for labeling drawings.
   In most applications the character stream is specified by its
   starting location in screen coordinates, the number of characters,
   and the location of a buffer of characters to be used.  In some
   purely output graphics systems the character stream is specified via
   a format similar to printer output, with the characters being placed
   in the specified area on the display.

   Items 5 and 6 of the above list primarily apply to displays like
   Sketchpad and the Evans and Sutherland display.  Viewport is taken to
   be synonymous with "observer parameters in the object space" while a
   window means "selected portion of the display surface".
   Transformations of instances refers to a feature of Sketchpad which
   allows multiple uses of the same "pattern" for a graphical element.

   Because new equipment is constantly coming into use, and special-
   purpose equipment is available at some nodes, it is prudent to have
   available a capability for sending equipment-specific information
   over the net as a part of the protocol.  Such information would be in
   the form of byte streams formatted according to the equipment
   specifications and pointed at the proper node and equipment.  It
   would not be expected that each node be able to interpret the
   nonstandard byte stream.  Also very equipment specific is the
   information passed from an interactive device back to the originating
   program.  Elements such as joystick or cursor position, lightpen
   hits, function buttons pressed, etc., are inherently dependent upon
   the device employed.  Although these devices are widely used, their
   general dependence upon display buffers, display lists, or interrupts
   is of special concern to the network graphics protocol.

   We are interested in expanding upon the uses of grey-scale display
   modes for representation of computer-generated data and for three-
   dimensional object representation.  To facilitate this, our system
   will have available at least four, program-callable display element
   types for production of pictures on grey-level display devices.  The
   initial names for these modes are the procedure names: GRIDAREA,
   MATRIXAREA, SCANLINE, and SCANPOINT.  The following paragraphs will
   outline how the modes operate both from a user and a data-



Kelley                                                          [Page 3]

RFC 184              Proposed Graphic Display Modes          6 July 1971


   communications point of view.  The specific hardware involved is not
   specified, nor do we ignore the possibility that hardware can be
   designed to operate this way directly.  For example, the SCANLINE is
   precisely the way one display does operate.  In the interim, however,
   software sits between these procedures and actual devices.

   GRIDAREA              The user specifies, in an initial call, the size
   --------              grid he wishes to use and the number of intensity
                         levels he will need.  Subsequent calls send, as
                         data items, the i, j locations of an area and a
                         byte for intensity.

   The initializing call is GRIDSET(N, M, IRNGE)
                                              |<--- I ------>|
   where N is the number of spaces       ---  +--+--+--+--+--+--+--+--+
   across, M is the number down,          ^   |--|--|--|--|--|--|--|--|
   and IRNGE tells how many grey          |   |--|--|--|--|--|--|--|--|
   levels to use.  This is primarily      J   |--|--|--|--|--|--|--|--|
   for grey-scale displays or             |   |--|--|--|--|--|--|--|--|
   pseudogrey-scale displays.             v   |--|--|--|--|--|--|--|--|
                                         ---  |--|--|--|--|--|--|--|--|
                                              |--|--|--|--|--|--|--|--|
                                              +--+--+--+--+--+--+--+--+