rfc965.txt

RFC 相关的技术文档

            Erase component P of object I
            I(c):  object identifier
            P(i):  pick id of component

            This erases a group of output primitives identified by P in
            a segment associated with I. This element can be used only
            within a REDEFINE OBJECT sequence.

      Items for Normalization Transformation

         SET WINDOW

            | 'GKSM 134' | L | W |

            Define boundaries of world window for normalization
            transformation.
            W(4r): limits of world window (XMIN, XMAX, YMIN, YMAX )

         SET VIEWPORT

            | 'GKSM 135' | L | V |

            Define boundaries of NDC viewport for normalization
            transformation.
            V(4r): limits of NDC viewport (XMIN, XMAX, YMIN, YMAX )










Aguilar                                                        [Page 17]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      Items for Other Operations

         ABORT

            | 'GKSM 136' | L |

            Abort ongoing operation transmitted in PIGCF stream. This
            provides the means to abort unwanted or erroneous
            operations. Only the innermost operation of a nested
            sequence is aborted; successive aborts can be used to get
            out of several levels of operation nesting.

         POINTER TRACKING

            | 'GKSM 137' | L | T | P |

            Update graphical pointer position to P
            T(i):  0 causes only cursor to be moved
                   1 causes cursor movement to be traced with
                   a line
            P(p):  a point sampled from graphical pointer
                   movement trace



























Aguilar                                                        [Page 18]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


         RUBBER BAND

            | 'GKSM 138' | L | T | P |

            Echo a rubber band of type T with given reference and
            feedback points. The first occurrence of this item in a
            sequence carries the coordinates of the echo reference
            point. Subsequent occurrences carry updates to a pointer
            position indicating an echo feedback point.

            T(i):  echo type
                   ( 0 echo reference point;
                   > 0 echo feedback:
                     1 = line,
                     2 = rectangle,
                     3 = circle )
            P(r):  echo reference point (T = 0),
                   or echo feedback point (T > 0)

               The reference and feedback points are:
                  T = 1 - reference is one end of line, feedback is
                          other end.
                  T = 2 - reference is one corner of rectangle, feedback
                          is opposite corner.
                  T = 3 - reference is center of circle, feedback is
                          perimeter point.

         RECALL LIBRARY

            | 'GKSM 139' | L | F |

            Recall graphical library in file F
            F(i):  name of file containing library

            The graphical pictures in F and all their components become
            available for use during the communication session. The
            pictures are assumed to be recorded with the PIGCF, and
            their components have to be displayed with DISPLAY OBJECT
            elements or similar actions so that the pictures become
            visible.









Aguilar                                                        [Page 19]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


V.  AN ARCHITECTURE FOR PIGCF PROCESSING

   This section presents an example software architecture for the
   generation and interpretation of PIGCF in a multimedia conferencing
   system using GKS as the underlying programmer's graphics interface.
   This section should not be interpreted as a definitive statement of
   such an architecture, but only as an exercise to illustrate how the
   format proposed in this paper fits within the overall framework of a
   conferencing system. Choosing GKS simplifies the example
   architecture; nevertheless, other graphics packages can be used by
   adding, to the architecture, the modules to interpret and generate
   the PIGCF level L items.

   Figure 1 shows the major software modules charged with graphics
   interaction and display at a conferencing workstation. This is a
   familiar programmer's view of the graphics pipeline. A conferencing
   application program updates data structures and uses
   device-independent graphics services through a language binding.
   These services, in turn, use device-dependent graphics services that
   call on device drivers to accept input and to present graphic
   pictures. The application performs numerous other functions for
   conference management and control of other media streams, but we need
   not consider them in this example.

   In Figure 2, the basic graphics pipeline has been augmented with the
   software modules involved in the generation, transmission, reception,
   and interpretation of PIGCF streams. The application has a module for
   interpreting the lower and higher levels of PIGCF and one for
   generating the upper level U. The device-independent graphics
   services include modules for generating and interpreting the lower
   level, L. This reflects the current practice of including the
   generation and interpretation functions in the graphics package.
   There is also a module that transmits the outgoing PIGCF streams to
   remote work stations. Similarly, there is a module that receives
   incoming streams from remote stations. In actual practice, the
   transmit and receive modules are decomposed into several processes
   implementing a layered protocol architecture. A process receives both
   levels of PIGCF and writes them into a conference record metafile for
   future use. A router process receives and forwards PIGCF traffic from
   and to the modules previously referred. This router is likely to be
   replaced by independent communication interfaces between pairs of
   modules exchanging PIGCF.

   The thick arrows show the flow of outgoing PIGCF, whereas the thin
   arrows show the incoming PIGCF flow. We first follow the outgoing
   path, starting at the application.  The application processes local
   user actions which are transformed into data structure updates, level


Aguilar                                                        [Page 20]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


   U PIGCF elements, and executions of device independent graphics
   subroutines that, among other things, generate level L PIGCF (GKSM)
   elements.

   The router merges both level streams according to generation order
   and sends them to the local copy of the conference record and to the
   transmission module. The latter batches Group-2 PIGCF items until it
   receives a Group-1 item. It also timestamps the PIGCF stream to
   synchronize its play-back, at the receiver, with the play-back of
   other media information.  The PIGCF may be separated into traffic
   categories transmitted over diverse communication facilities
   according to the transport services required by the categories, for
   example, real-time service for pointer updates, highly reliable
   transmission for new object definitions, or low-priority service for
   graphical library transfers. Finally, the transmit module must
   acknowledge the reception of incoming PIGCF, and of other media
   traffic as well.

   The receive module is the entry point for incoming PIGCF streams that
   may come within diverse traffic categories requiring merging. It
   checks the timestamps for synchronizing PIGCF items with related data
   in other media, for example, voice. It is possible to include here a
   high-level error-correction function that validates the received
   streams using state and context information about PIGCF syntax and
   semantics. The receive module passes the streams to the router which
   forwards them to three processes: It sends level L items to the GKSM
   interpreter which produces the corresponding changes on the displayed
   picture; it sends level L and level U items to the conference record,
   as well as to the PIGCF interpretation code in the application. The
   level U items cause updates to both the data structures modeling
   object hierarchies, and the pictorial representation of the
   hierarchies, through the execution of graphics services. U items also
   update graphics cursors and may recall new graphics libraries. The
   application must process level L items because they could indicate
   updates to the data structures; this happens if, for example, the
   structures record attribute value information for the object
   hierarchies. The application coordinates these actions with other
   media effects according to the timestamps. Conference record
   play-back is done in off-line mode. Record items are received by the
   router and thereafter processed similarly to incoming PIGCF.









Aguilar                                                        [Page 21]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


                 +------------+        +-------------+
                 |APPLICATION |        |    OTHER    |
                 |    DATA    |        |    MEDIA    |
                 |STRUCTURES  |        |-------------|
                 +-----|------+        |  CONFERENCE |
                       |---------->    | APPLICATION |
                                       |   GRAPHICS  |
                       |---------->    |             |
                 +-----|------+        |             |
                 |  LANGUAGE  |        +-------------+
                 |  BINDING   |                       
                 +-----|------+        +-------------+
                       |---------->    |   DEVICE-   |
                 +------------+        | INDEPENDENT |
                 |  DEVICE    |        |   GRAPHICS  |
                 |  DEPENDENT |  <---> |   SERVICES  |
                 |  GRAPHICS  |        |             |
                 |  SERVICES  |        |             |
                 +-----|------+        |             |
                       |               |             |
                       v               |             |
                 +------------+        |             |
                 |    DEVICE  |        |             |
                 |  DRIVERS   |        |             |
                 +------------+        +-------------+

                 FIGURE 1 - THE BASIC GRAPHICS PIPELINE
                        IN A CONFERENCING SYSTEM