path: root/doc/rfc/rfc184.txt

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]
^L
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]
^L
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]
^L
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   |--|--|--|--|--|--|--|--|
                                         ---  |--|--|--|--|--|--|--|--|
                                              |--|--|--|--|--|--|--|--|
                                              +--+--+--+--+--+--+--+--+

   On a Gould Electrostatic Printer-Plotter, for example, the system
   would expect to have dot patterns with which to fill areas in order
   to simulate the greys.  For purposes of other displays, a SETSQUARES
   procedure should be available so that the user can specify various
   kinds of cross- hatching and character filling to apply to the grid
   areas.

   To enter an item of data the procedure is

                                              1 <= I <= N
                  GRIDAREA(I, J, LEVEL)       1 <= J <= M
                                              1 <= LEVEL <= IRNGE

   where I and J select an area on the grid, and LEVEL tells how to fill
   it.  Obviously, for this kind of display mode some provision must be
   made to end the picture because the servicing routine will have to
   work on it from either the top or the bottom in a sweep mode.  A
   procedure call of GRIDAREA(0, 0, 0) will terminate it.  The GRIDAREA
   mode is very similar to the following, MATRIXAREA, with the primary
   difference being that the specification of areas is random and areas
   which are not specified will be left blank.






Kelley                                                          [Page 4]
^L
RFC 184              Proposed Graphic Display Modes          6 July 1971


   MATRIXAREA            The user specifies an area size and a "pseudo-
   ----------            character" set, then writes from left to right,
                         top to bottom, much like a line printer, using
                         bytes to specify which of his "pseudo-character"
                         set to use.

The initializing call is MATRIXSET(N, M, DEFINITION, CODE)

The display mode is raster                ________________________
oriented, and each "pseudo-              |  _   _   _   _   _   _ |
character" will be on a N x M            | |_| |_| |_| |_| |_| |_||
matrix of dots.  (A later                |  _   _   _             |
embellishment for printers               | |_| |_| |_| . . .      |
would include matrix of characters.)     |  _   _                 |
Parameters DEFINITION and CODE           | |_| |_| . . .          |
are both arrays, used together to        | .    \ \               |
specify the "pseudo-character" set.      | .     \  \             |
DEFINITION is packed with bits           |________\___\___________|
according to the following scheme:                \     \
                                                   \      \
                                                    \    __\_______
                                                     \  /           \
                                                      \/  ________   \
                                                      /   |_|_|_|_|   \
                                                     /    |_|_|_|_|    \
                                                     |    |_|_|_|_|    |
                                                     |    |_|_|_|_|    |
                                                     \    |_|_|_|_|    /
                                                      \   |_|_|_|_|   /
                                                       \             /
                                                        \___________/

     n - bits
    +--+--+--+--+
    |XX|  |  |XX|
    |--|--|--|--|
s   |  |XX|XX|  |
t   |--|--|--|--|
i   |XX|  |  |XX|
b   |--|--|--|--        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--\
    |  |XX|XX|  |  <=== |1|0|0|1|0|1|1|0|1|0|0|1|0|1|1|0|1|0|0|1|0|1|1|0|\
-   |--|--|--|--|       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\
m   |XX|  |  |XX|        \--v--/ \--v--/ \--v--/ \--v--/ \--v--/ \--v--/
    |--|--|--|--|           n       n       n       n       n       n
    |  |XX|XX|  |
    +--+--+--+--+        \-------------------------v---------------------/
                                                   m-groups




Kelley                                                          [Page 5]
^L
RFC 184              Proposed Graphic Display Modes          6 July 1971


   The bit stream for the definition is irrespective of word boundaries.
   We leave it up to the MATRIXSET routine to be able to undo this.
   Obviously, for user convenience we have some standard sets they can
   use to save having to define their own, and if they want to define
   their own, we make routines to ease the pain.

   The array CODE, on the other hand, is a byte-stream, i.e., a stream
   of eight-bit groups of bits which will correspond to each of the
   groups of (N x M)-bits.  This allows 256 pseudocharacters for one
   set.

   To enter an item of data in this mode the procedure is

                  MATRIXAREA(ARRAY, LENGTH)

   ARRAY is a buffer location and length is the number of code bytes
   which are to be put out.  Each call will put out one row of the
   display.  Unused bytes at the end of the stream (bytes left over in
   the last word) should be zero.  Any codes in excess of the maximum
   number allowed on a line will be discarded.

   It should be noted that this routine is nominally used for special
   character sets, or for that matter, any character sets that are
   software generated on dot-raster devices.  In addition, however, it
   can be used for photomosaic displays, area filling on maps, and
   development of capability of producing audiovisual aids for
   presentations.


   SCANLINE               A raster-scanning display mode for which the
   --------               user specifies a raster size, number of grey
                          levels needed, and direction of scan.  The
                          subsequent data items specify only the location
                          and character of a change in the scanning
                          beam (or program).

   The initializing procedure is SCANLINESET(DELTA, LEVELS, ORGMODE)

   DELTA is an integer specifying the number of display points to be
   included in each step.  LEVELS denotes the number of intensity levels
   to be used, and the sign of ORGMODE specifies whether the scan is to
   be from the bottom up (plus) or top down (minus) on the display.  For
   both cases we will assume left-to-right.  The absolute value of
   ORGMODE gives the starting Y position.

   All subsequent calls to this routine are of the form

                          SCANLINE(X, INTENSITY)



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


   The first such call denotes the origin in X and the initial
   intensity.  Subsequent calls denote the X value of the next point on
   the scan where the intensity is to change, and that new intensity.
   The program (or device) takes care of the stepping of the scan by
   DELTA across the page, with the current intensity.  Thus, the program
   (device) only needs a data item for each change in the scan, not for
   each position.  When the next X is less than the previous X, or the X
   position has been stepped to its limit, the Y position in the
   incremented or decremented to continue the scan on the next line.

   We see the device which accepts such a display as accepting a stream
   of triplets of bytes, where the first two bytes (16 bits) specify the
   X and the third (8 bits) specifies the level.  The end of the stream
   would be specified by three bytes of deletes (all ones).  This
   display mode is implemented in hardware on the display at the
   Coordinated Science Laboratory at this University.  It is the same
   one which was used for the grey-scale work which has been reported by
   Bouknight.


   SCANPOINT            A point with intensity scanning mode in which
   ---------            the scan is handled automatically and only the
                        intensity of each point needs to be transmitted
                        to the program (device).

   The initializing call for this procedure is

           SCANPOINTSET(DELTA, LEVELS, ORGMODE)

   The arguments are the same as for SCANLINE.  The difference is in the
   meaning of subsequent calls.  The origin for the scan is at the left
   end of the line corresponding to the absolute value of ORGMODE.  The
   stepping is done from left to right and at the end of each line, the
   Y position is incremented or decremented by DELTA, according to the
   sign of ORGMODE.

   Subsequent calls to this procedure are of the form SCANPOINT(LEVEL)
   where LEVEL denotes the intensity level at which the next point is to
   be displayed.  In this mode every point must have its intensity
   specified by a separate call to the routine (byte to the device).
   However, beyond the starting point no position information is
   required.


       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Hamid Dastkar 09/99 ]





Kelley                                                          [Page 7]
^L