Request for Comments: 965 SRI International
December 1985
A Format for a Graphical Communication Protocol
STATUS OF THIS MEMO
This paper describes the requirements for a graphical format on which
to base a graphical on-line communication protocol. The proposal is
an Interactive Graphical Communication Format using the GKSM session
metafile. Distribution of this memo is unlimited.
ABSTRACT
This paper describes the requirements for a graphical format on which
to base a graphical on-line communication protocol. It is argued that
on-line graphical communication is similar to graphical session
capture, and thus we propose an Interactive Graphical Communication
Format using the GKSM session metafile.
We discuss the items that we believe complement the GKSM metafile as
a format for on-line interactive exchanges. One key application area
of such a format is multi-media on-line conferencing; therefore, we
present a conferencing software architecture for processing the
proposed format. We make this format specification available to those
planning multi-media conferencing systems as a contribution toward
the development of a graphical communication protocol that will
permit the interoperation of these systems.
We hope this contribution will encourage the discussion of multimedia
data exchange and the proposal of solutions. At SRI, we stay open to
the exploration of alternatives and we will continue our research and
development work in this problem area.
ACKNOWLEDGEMENTS
The author wants to thank Andy Poggio of SRI who made many insightful
and valuable suggestions that trimmed and improved level U. His
expertise in multi-media communication systems and his encouragement
were a most positive input to the creation of this IGCF. Dave
Worthington of SRI also participated in the project discussions
involving this IGCF. Thanks are also due to Tom Powers, chairman of
ANSI X3H33, who opened this forum to the presentation of an earlier
version of this paper, thereby providing an opportunity for the
invaluable feedback of the X3H33 members. Jon Postel of ISI
recommended a number of changes that made this paper more coherent
and accessible.
RFC965 December 1985
A Format for a Graphical Communication Protocol
Most of the work reported in this paper was sponsored by the U.S.
Navy, Naval Electronic Systems Command, Washington D.C., under
Contract No. N00039-83-K-0623.
I. INTRODUCTION
A. Use of a Graphical Communication Protocol
In the field of computer communications, a protocol is a procedure
executed by two cooperating processes in order to attain a
meaningful exchange of information. A graphical communication
protocol is needed to exchange interactive vector graphics
information, possibly in conjunction with other information media
like voice, text, and video. Within this multi-media communication
environment, computer vector graphics plays a key role because it
takes full advantage of the processing capabilities of
communicating computers and human users, and thus it is far more
compact than digital images which are not generated from data
structures containing positional information. Vector graphical
communication trades intensive use of storage and processing, at
the communicating ends, in return for a low volume of exchanged
data, because workstations with graphical hardware exchange
graphics commands in conjunction with large data structures at the
transmitter and receivers. In this manner, the transmission of a
single command can produce extensive changes in the data displayed
at the sending and receiving ends.
It is helpful to situate the aforesaid protocol at one of the
functional levels of the ISO Open Systems Interconnection
Reference Model [1]. Within such a model, a graphical protocol
functionality belongs primarily in the application level, though
some of it fits in the presentation level. We can distinguish the
following components of a communication protocol:
a) a data format
b) rules to interpret transmitted data
c) state information tables
d) message exchange rules
A format for a graphical protocol should provide the layout of the
transmitted data, and indicate how the formated data are
associated with interpretation rules. The choice of format
influences the state tables to be maintained for the correct
processing of the transmitted data stream. The graphical format
has a minor influence on the exchange rules, which should provide
for the efficient use of transmission capacity to transport the
data under such a format. Besides the graphical format, there are
RFC965 December 1985
A Format for a Graphical Communication Protocol
other aspects of a graphical protocol that determine state tables
and exchange rules. This paper concentrates in the data format,
and it does not discuss the message exchange. Nevertheless, we
discuss a simple software architecture for generating and
interpreting data streams written in our proposed format. Further,
we give an example of an application of a proposed format (in
Appendix B), and it illustrates the type of message exchanges that
are needed for establishing a communication session and exchanging
graphical information.
Those in the computer communication field are well aware of the
importance of widely accepted protocols in order to achieve
meaningful communication. Those who need to implement interactive
graphical communications today are confronted with the lack of an
standard for computer graphics communication among application
programs. Nevertheless, we can use some of the work already done
by the computer graphics standard bodies. As a matter of fact, ISO
and ANSI have already appended, to the Graphical Kernel System
(GKS) standard, the GKSM session metafile specification that has
many of the features needed for an on-line graphical protocol.
It is pertinent to mention an example of graphical communication
that illustrates the real-time nature of the interaction and also
illustrates the use of graphics in conjunction with other
information media. With audio-graphics conferencing, a group of
individuals at two or more locations can carry on an electronic
meeting. They can converse over voice channels and concurrently
share a graphics space on which they can display, point at, and
manipulate vector graphics pictures [2, 3, 4, 5, 6, 7].
The conference voice channels can be provided by a variety of
transmission technologies. The shared graphics space can be
implemented on workstations that display the pictures and permit
graphical interaction and communication with other locations. The
communication of operations upon pictures involves modifications
to the underlying data structures, but we are concerned with
graphical database updating only to the extent that such updating
supports the communication.
In order to play out a recorded graphical session, we will need
indications of the rate at which the graphical elements must be
shown and the graphical operations recreated. We do not include
the means for indicating the timing of a session in a format
because our main purpose is to use it in mixed-media communication
environments. In these environments, the play-out timing must be
compatible across information media in order to coordinate them.
Therefore, we leave the timing mechanisms to conference-control
RFC965 December 1985
A Format for a Graphical Communication Protocol
modules. We also leave to conference control processes the manner
in which a conferee station emulates a graphical capability that
it lacks. One example is the representation of color in monochrome
displays.
B. Relationship to Other Work
There are a number of actual, and proposed, standards for graphics
information exchange. In the following, we explain the reasons
why, at present, none of them can be used as the basis of an
on-line protocol. As some of these standards evolve, however, some
may become suitable. Moreover, the experience gained with early
on-line graphics communication systems will provide insight into
the proper standard extensions to support more advanced systems.
Such insight could also be used to modify the format proposed in
this paper, which we consider an initial approach to the problem.
In the future, the format proposed in this paper could be replaced
by one of the aforesaid extended standards.
The North American Presentation Level Protocol Syntax, NAPLPS,
specifies a data syntax and application semantics for one-way
teletext information dissemination and two-way videotex database
access and transaction services. The two-way videotex operational
model is based on the concept of a consumer and an information
provider or service operator. Because of this asymmetry, it is
assumed that almost all graphical information will flow from the
provider toward the consumer. In the reverse direction, the
consumer is expected to manipulate and transmit alphanumeric
information, for the most part. Although this standard includes
geometric drawing primitives, a user cannot directly modify shapes
drawn with the primitives.
At present, NAPLPS does not include interaction concepts like
picture transformations or detectability, which are fundamental
for attaining a shared graphical workspace. Neither does it allow
key graphics input devices like mice, joysticks, stylus, rotating
balls, or light pens, which are needed for simple and efficient
editing of the shared workspace.
We want to have user-to-user graphical communication that features
the level of sophistication and ease of interaction provided by
today's interactive graphics packages. Computer vector graphics
can provide both because its paradigm includes an application
program that keeps track of a very large number of possible
changes of state of the displayed picture. In addition, the
application drives a powerful graphics package, like GKS or ACM
Core. In the videotex paradigm, the provider application only
RFC965 December 1985
A Format for a Graphical Communication Protocol
allows limited changes to the displayed image, primarily database
retrieval requests. Also, the paradigm does not include a separate
graphics package. Both the graphics functionality and the data
format are collapsed into a coding specification, like NAPLPS.
In this paper we are interested primarily in business and
industrial applications where there is a two-way, or multi-way,
flow of vector graphics information among the users. The users
will have workstations with substantial processing and storage
capacities, and high-resolution monitors; moreover, the
communication will be on a distributed architecture not depending
on a central server host, like the provider application host of
videotex.
Currently, the videotex equipment at the consumer end consists of
inexpensive microprocessor-based decoders or personal computer
boards driving, in most cases, low-resolution standard TV sets and
personal computer displays. There is already affordable technology
to produce sophisticated decoders and high-resolution graphics
devices. The videotex standards need extensive revisions to take
advantage of these advances; in particular, they should consider
the receiving devices as capable of hosting a programmable
customer-application process. When this happens, videotex
protocols will be applicable to our intended problem areas [8].
The Computer Graphics Metafile [9] will become an international
and North American standard for graphics picture interchange in
the near future. However, the CGM, also referred as VDM, is a
picture-capture metafile that only records the final result of a
graphics session. It is not intended to record the
picture-creation process, which is fundamental for the interactive
applications that we are addressing. Moreover, the CGM is
presently aimed at a minimum support of GKS functionality. It will
be some time before the CGM will have some of the elements needed
for on-line interaction. If, after these additions, the CGM is
augmented for session capture, it would become a logical candidate
for a protocol format.
Another future standard is the Computer Graphics Interface, CGI
also referred as VDI [10]. The CGI is a standard functional and
syntactical specification of the control and data exchange between
device-independent graphics software and one or more
device-dependent graphics device drivers. A major use of the CGI
is for the communication between an application host and a
graphics device, but the asymmetry between its intended
communicating ends hinders the use of CGI for our purposes.
RFC965 December 1985
A Format for a Graphical Communication Protocol
As previously stated, we want to take advantage of intelligence
and storage at the communicating ends in order to achieve powerful
information-conveying effects using narrow-bandwidth channels.
This requires that the format we seek must have items for
communication between two applications. In contrast, the CGI
streams are processed by device-dependent drivers, rather than by
applications. The CGI specification does include application data
elements, but only to be stored in a metafile. These application
data elements are not interpreted by the drivers, but by
applications that read the metafile, some time after metafile
creation.
Furthermore, the CGI has elements for obtaining graphical input,
as well as elements for inquiring graphics device capabilities,
characteristics, and states. Later, in Section III, we explain why
these two classes of elements are unnecessary for the
communication protocol we need. As the CGI evolves, it will
undergo significant changes, and, in the future, it may become a
very suitable kernel for the graphics protocol we seek. As a
matter of fact, the CGI will be the communication protocol between
graphical application hosts and graphics terminals. At SRI we are
tracking its evolution, and we are interested in defining a format
based on the CGI.
Finally, the Initial Graphics Exchange Specification [11] is not
aimed at our primary area of interest. The IGES defines standard
file and language formats for storing and transmitting
product-definition data that can be used, in part, to generate
engineering drawings and other graphical representations of
engineering products. Besides the CAD orientation of IGES, the
graphical output function may be secondary to other goals like
transmitting numerical-control machine instructions.
II. OPERATIONAL REQUIREMENTS AND USABILITY
The main goal of this paper is to lay the groundwork for the
development of a vector graphics format to be used as a basis for an
on-line graphical communication protocol. We call such a format an
"interactive graphical communication format," or IGCF. In this
section we describe some operational requirements and usable
characteristics for an IGCF.
A. Interoperation of Heterogeneous Systems
A first functional requirement is that an IGCF must permit
communication among heterogeneous graphical systems differing both
in the hardware used and in the software of their graphics
RFC965 December 1985
A Format for a Graphical Communication Protocol
application interfaces. This is a fundamental for attaining
communication among similar graphical application programs running
on dissimilar hardware and using dissimilar graphics interface
packages. Some examples of such application programs are graphics
editors, CAD systems, and graphical database retrieval programs
communicating with other editors, CAD programs, and graphical
databases, respectively.
B. Picture Capture
A required characteristic of an IGCF is that it must be usable for
the exchange of static graphic pictures, i.e. for picture capture;
yet, it must not be restricted to final picture recording only.
There will be picture exchanges as part of the interactive
communication, and we anticipate the need to record the state of a
picture at some points during the on-line graphics engagement. We
foresee the creation of graphical IGCF libraries containing object
definitions and pictures for inclusion in new pictures. Since
metafiles have been used for a long time to capture pictures,
there is a strong motivation to base an IGCF on a metafile
standard in order to secure compatibility with a large number of
metafile sources and consumers.
C. Prompt Transmission
In some forms of interactive graphical communication, like
audiographics conferencing, it is critical to convey across users
the real-time nature of the interaction. This dictates that object
creations and manipulations be transmitted as they happen rather
than as a final result since a substantial part of the information
may be transmitted concurrently with the construction or operation
of an object, possibly through associated media like voice. Since
both construction and manipulation processes have to be
transmitted, there is a limit to the number of intermediate states
that can be economically transmitted.
A third requirement is, therefore, that the IGCF elements provide
fine "granularity" to convey the dynamics of the constructions and
manipulations. We believe that it is sufficient that the IGCF have
basic construction elements like polygons, markers, polylines, and
text strings and that it transmit them only when they are
completed; i.e., it is not necessary to transmit partial
constructions of such elements.
The problem for manipulations extends beyond an IGCF. Whereas we
know that an IGCF should include segment transformations, segment
highlighting and segment visibility on/off, the transmitter must
RFC965 December 1985
A Format for a Graphical Communication Protocol
decide how often to sample an on-going transformation and transmit
its current state. The choice of a sampling frequency will depend
on the available transmission bandwidth.
D. Low Traffic Volume
In many of the applications we envision, coordinate graphics will
be transmitted over narrow bandwidth channels, and thus it is
essential to minimize traffic. Accordingly, several requirements
are imposed on an IGCF to take advantage of the characteristics of
the graphics communication intercourse and architecture in order
to minimize traffic.
An IGCF can help reduce traffic by including the basic geometric
objects from which so many other objects are built. Moreover, an
IGCF should permit the use of objects for the creation of more
complex objects; since reuse is very common, the result is a
reduction of traffic and storage cost.
E. Preservation of Application Semantic Units
A related requirement is that an IGCF must include elements to
represent graphical objects corresponding to real world entities
of the intended applications. For example, in a Navy application,
the entities of interest are carriers, submarines, planes, and the
like. We want to communicate such semantic units across systems
and to treat them as unitary objects because, in many
applications, communication is based on creating and operating
such units. If an IGCF has elements to represent such semantic
units, the communication traffic decreases because the entity
definitions can be transmitted only once and then reused, and
because the entities are manipulated as units rather than
separately manipulating their components.
It turns out that there is a small set of primary operations that
can be applied to a graphical object, and an IGCF must have
elements representing such operations. In contrast to dumb
graphics terminals receiving screen refresh information from a
host, we foresee graphical communication taking place among
intelligent workstations that can exchange encoded operations,
interpret them, and apply them to objects stored locally.
F. Transmission Batching
We previously indicated the desirability of conveying to the human
users the real-time tempo of interactive graphics exchanges.
However, it is possible to do so without having to transmit
RFC965 December 1985
A Format for a Graphical Communication Protocol
immediately all IGCF elements. As a matter of fact, IGCF elements
should be divided into those causing a change on a displayed
picture and those that do not, although both classes may cause
changes to the stored graphical data structures.
It is only necessary to transmit immediately those elements
causing a visible change on a displayed picture because they are
the ones whose reception and interpretation delivers information
to a human user. The second class of elements can be batched and
queued for transmission until one element of the first class is
submitted. We call the first class update Group-1, and the second,
update Group-2.
The aforesaid division is quite important for packet
communications because each packet contains a hefty amount of
overhead control traffic. It is therefore mandatory to batch, into
a packet, as much client data as possible in order to reduce total
traffic. The batching units can be varied in size according to the
network traffic and response time of conference hosts. During
congested periods, the units may have to be increased, thus
lowering the number of messages, and then reduced when congestion
eases, thus increasing the number of messages.
G. Simple Translation Between IGCF and User Interface
According to the first requirement, an IGCF must permit the
interoperation of related heterogeneous graphics applications.
Such interoperation has, as an objective, the communication
between human users or between a human and a database.
Correspondingly, the interoperation involves a mapping between the
user interface commands and the IGCF elements. It is not advisable
to use the commands themselves as the IGCF elements; otherwise the
exchange would depend on the communicating systems, and every pair
of communicating systems would require an ad-hoc protocol.
An additional usability characteristic is that there must be a
simple mapping between IGCF elements and the actions represented
by the user interface commands employed for graphical
communications. This simplicity is a must because every
communicating graphical system must have a translator that ideally
should be very simple. It seems that the inclusion of command
sequence delimiters in the IGCF helps the simplicity since the
delimiters permit keeping a smaller amount of state information
for processing an IGCF stream.
We have verified the mapping from one set of commands for
audiographics conferencing to the IGCF proposed in this paper. The
RFC965 December 1985
A Format for a Graphical Communication Protocol
mapping from user interface commands to IGCF can be done in a
direct and efficient manner; on the other hand, the reverse
mapping, from IGCF to user interface commands, is a more difficult
task. We anticipate that, in order to improve performance, we will
have to map the IGCF elements to calls to lower level subroutines
implementing the user interface actions. Whereas such mapping is
conceptually no more complex than translating IGCF to the commands
themselves, it will require considerably more programming.
III. ELEMENTS OF AN IGCF
IGCF Element Classes
In this section we list the classes of elements that we believe an
IGCF should have in order to exchange vector graphics under the
requirements of the previous section. The classes correspond to
the common function classes in computer graphics interfaces, and
each contains elements corresponding to interface primitives and
attributes. We do not list the elements for each class because
they are exemplified by the elements in the proposed IGCF.
In the following list, two categories of functions are missing:
functions used to query the status of a graphics system, and input
functions. As a matter of fact, an IGCF only needs to have
elements representing actions that cause a change in the state of
the communicating graphical systems, and the inquire functions
obviously do not change their state. Even though an input function
executed at the transmitting end causes a local change, it is not
necessary to transmit the input command itself. The receivers only
need to get the data input, in IGCF representation, and they can
process the data in any manner, maybe simulating local input
actions.
Control
Elements for workstation: initialization, control and
transformation; and elements for normalization transformation.
(The normalization and workstation transformations can be used
to implement zooming.)
Primitive attributes
Elements for primitive, segment, and workstation attributes.
Output primitives
Elements for output primitives.
RFC965 December 1985
A Format for a Graphical Communication Protocol
Segmentation
Elements for basic segmentation and workstation independent
segment storage.
Object manipulations can be implemented with segment
transformations. Object insertion can be implemented using
segment recall and segment visibility. Object deletion can be
implemented using segment deletion and segment visibility.
Object selection can use segment highlighting as feedback to
the user.
Dynamics
A considerable part of the graphical information exchanged
through an IGCF will be in the form of pointer movements over a
background picture. Pointer tracking is used to transmit points
sampled from a graphical pointer trace in order to reproduce,
at the receivers, the movement of the pointer at the sender
site. This can be done either by just moving the cursor or by
tracing its movement with a line. Rubber band echoes are used
to signal areas, routes, and scopes in a highly dynamic way.
These are indicated by an echo reference point and a feedback
point.
Hierarchical object definitions
The requirement for preserving application semantics dictated that
an IGCF include the means to represent objects that stand for
application entities, and to manipulate such entities as graphical
units. Furthermore, the low-traffic-volume requirement called for
the use of already existing objects for the creation of new ones.
One way to meet the aforesaid requirements is by including in an
IGCF the means to represent object hierarchies. In such a
hierarchy an object is a set of output primitives associated with
a set of attribute values or a set of lower-level objects, each
associated with a composition of transformations [12].
Graphics segments can be used to implement objects in the lowest
level of a hierarchy. The definition of a higher-level object can
be represented by sequences of IGCF elements describing the
definition process. Such a definition can be done by instantiating
lower-level objects with specific transformation parameters. Thus
an IGCF must incorporate brackets to mark the beginning and end of
object definitions, object instantiations, and object
redefinitions.
RFC965 December 1985
A Format for a Graphical Communication Protocol
In order to complement the mechanism for object definition, an
IGCF must permit the use of a flexible alphabet for creating
object identifiers that ensure the uniqueness of an identifier in
a hierarchy. The construction of the object identifiers is not
part of an IGCF, an IGCF only has to represent the identifiers.
Further, an identifier has to be independent of a communication
session and a particular graphics system so that identifiers
created at a host during one session can be used, in other
sessions possibly involving other hosts, to recall the objects
they label.
We also leave to the communicating systems the implementation of
mechanisms to resolve duplicate identifiers when merging two
hierarchies, created in different sessions. In this paper we shall
limit ourselves to the warning that segment numbers do not qualify
as identifiers because they depend on the session and state of the
system in which they are created.
In addition to object definition and instantiation, an IGCF should
have elements representing operations on objects. The operations
so far identified are: transformation, deletion, display,
disappearance, expose, and hide. Expose is used to uncover objects
on a screen that are hidden by other objects; hide is used to
place an object behind others on a screen.
IV. A PROPOSED IGCF
A. Using the GKSM as a Basis
An IGCF must be usable to transmit all graphical actions in a
conference session. This suggests to base an IGCF on a standard
session-capture graphics metafile, thus ensuring compatibility
with a large user population. We have based the proposed IGCF,
PIGCF, on the GKSM session-capture metafile specification because
GKSM contains many of the elements identified for an IGCF [14]. In
addition, the audit trail orientation of GKSM permits the
recording of interactive communication sessions for later play
out, and this is a feature that we anticipate will be frequently
used.
The GKSM is a proper subset of our PIGCF and thus any graphical
system developed to handle the PIGCF, can read a GKSM metafile.
Conversely, the applications using the PIGCF should have an option
for constraining session recording only to the GKSM part, possibly
suppressing some session events. By doing so, we will be able to
ship a GKSM metafile to any correspondent who has GKSM
RFC965 December 1985
A Format for a Graphical Communication Protocol
interpretation software. Alternatively, an application with a
GKSM interpreter but without an PIGCF interpreter can read a PIGCF
file interpreting only the GKSM part and ignoring the rest.
Whereas the GKSM was specified for the GKS system, we believe that
the GKSM is a sound and general basis for all of our 2-D
applications. We feel that the GKSM specification is not parochial
to GKS systems but contains all the most useful items desired in a
metafile. In the future, we expect to tackle applications
requiring 3-D, like interactive repair and maintenance aids. When
GKS be augmented with 3-D capabilities [13], we will extend the
PIGCF with any necessary elements.
We are aware that the GKSM specification is not part of the GKS
standard itself but is an appendix recommending such a metafile
format. Nevertheless, all the GKS vendor implementations that we
know of, at the present time, support GKSM metafile output and
interpretation. If this trend continues, as we expect, we will be
able to exchange graphical files with a large base of GKS
installations. There will indeed be many of them since GKS will be
adopted as an standard by ISO and by many national standard bodies
in the near future.
B. Positional Information Coordinates
Following the GKSM convention, the PIGCF positional information is
in normalized device coordinates, NDC. Thus the originator of a
conference must indicate the workstation window for the
conference. This window is the sub-rectangle of the NDC space
enclosing the area of interest for the conference. In most cases,
the participating workstations will take this window as their own.
However, the graphical systems should provide for the possibility
of a workstation choosing a different workstation window, which
may contain the conference window or just overlap it. Except for
special cases, a conference originator should not state a
conference workstation viewport. In this manner, each workstation
can display its workstation viewport in the most convenient
portion of the screen.
There will be conferences where the participating workstations
will maintain the positional information in world coordinates, WC.
It might be necessary to reconstruct the world dimensions after
transmission because such dimensions have a relevant meaning for
the application, like sizes of components or distances. In this
case, a workstation will have to map from WC to NDC before
transmitting and from NDC to WC after receiving. At the outset,
the conference originator has to specify the world window and the
RFC965 December 1985
A Format for a Graphical Communication Protocol
NDC viewport used in the conference in order for the conferencing
workstations to do such mappings. These mappings could be done by
the presentation layer, in terms of the ISO Open Systems
Interconnection Reference Model, in a manner that is transparent
to the communicating application programs.
Most often all workstations will have the same world windows and
NDC viewports. However, the graphical systems will provide for the
possibility of a workstation choosing a different window or
viewport, but such workstation will have to record the conference
ones for doing the aforesaid mappings. There are graphical
systems, like the ACM Core, that do not provide for a workstation
transformation. In such systems, the NDC viewport is considered to
be the workstation window for the aforesaid mappings.
C. Layers of the PIGCF
There are two levels in the PIGCF a lower level L and an upper one
U. The lower level L is just the GKSM metafile specification as
defined in Appendix E of the proposed GKS ANSI standard [14]. We
have excerpted most of Appendix E of [14] at the end of this RFC
as our Appendix A. All level L elements belong to the update
Group-1 except: SET DEFERRAL STATE, the output primitive attribute
elements, the workstation attribute elements, CLIPPING RECTANGLE,
CREATE SEGMENT, CLOSE SEGMENT, RENAME SEGMENT, SET SEGMENT
PRIORITY, and SET DETECTABILITY.
The upper level U is those elements that we believe complement the
GKSM for general on-line graphical exchanges. This layering
conforms to the graphics metafile level-structure described in
Enderle et. al [15]. Under such structuring, an application
oriented metafile can be based on graphical metafiles.
D. PIGCF Elements in the Level U
The level U items are encoded as GKSM user item elements so that a
PIGCF file will conform to the GKSM metafile specification.
Accordingly, a PIGCF file will be a GKSM metafile in its entirety.
We use the same formatting conventions as the GKSM specification.
Those unfamiliar with these conventions should read the beginning
of the appendix. The following items belong to the second update
group: the two items for object definition, the two items for
object redefinition, the two items for object instantiation, the
two items for normalization transformation, SELECT COMPONENT, and
RECALL LIBRARY. The remaining items belong to the first update
group.
RFC965 December 1985
A Format for a Graphical Communication Protocol
Items for Object Definition
BEGIN DEFINITION
| 'GKSM 120' | L |
Indicates beginning of object definition sequence
END DEFINITION
| 'GKSM 121' | L | I |
Indicates end of object definition sequence. I(Nc): object
identifier ( N preceding c, i, r means an arbitrary number
of characters, integers, or reals.) Objects defined
interactively are made visible on the screen; i.e. they are
automatically instantiated. If only the definition is to be
kept but not the image, a DISAPPEAR item must follow.
BEGIN REDEFINITION
| 'GKSM 122' | L | I |
Indicates beginning of object redefinition sequence
I(Nc): object identifier
END REDEFINITION
| 'GKSM 123' | L |
Indicates end of object redefinition sequence
Items for Object Instantiation
BEGIN INSTANTIATION
| 'GKSM 124' | L | I |
Indicates beginning of object instantiation sequence
I(Nc): Object identifier
END INSTANTIATION
| 'GKSM 125' | L |
Indicates end of object instantiation sequence
RFC965 December 1985
A Format for a Graphical Communication Protocol
Items for Object Manipulation
TRANSFORM OBJECT
| 'GKSM 126' | L | C | I | M |
Apply transformation M to object I
C: number of characters in identifier
I(Nc): object id
M(6r): upper and center rows of a 3x3 matrix representing
a 2D homogeneous transformation [12].
M 11 M 12 M 13 M 21 M 22 M 23
DELETE OBJECT
| 'GKSM 127' | L | I |
I(Nc): object identifier
DISPLAY OBJECT
| 'GKSM 128' | L | I |
Turn on visibility of object I
I(Nc): object identifier
DISAPPEAR OBJECT
| 'GKSM 129' | L | I |
Turn off visibility of object I
I(Nc): object identifier
EXPOSE OBJECT
| 'GKSM 130' | L | I |
Redisplay object I on top of any overlapping objects
I(c): object identifier
HIDE OBJECT
| 'GKSM 131' | L | I |
Redisplay object I behind any overlapping objects
I(c): object identifier
RFC965 December 1985
A Format for a Graphical Communication Protocol
SELECT COMPONENT
| 'GKSM 132' | L | I | P |
Select component P of object I
I(c): object identifier
P(i): pick id of component
This is used to select a group of output primitives
identified by P in a segment associated with I.
ERASE COMPONENT
| 'GKSM 133' | L | I | P |
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 )
RFC965 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
RFC965 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.
RFC965 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
RFC965 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.
RFC965 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
RFC965 December 1985
A Format for a Graphical Communication Protocol
+------------+ +------------+ +------------------+
|APPLICATION | | OTHER | | TRANSMIT |
| DATA | | MEDIA | | ACK |=>
| STRUCTURES | |------------| +-----+ | SEPARATE TRAFFIC |=>
+-----|------+ | CONFERENCE | | |===> | BATCHING |=>
|---------->|APPLICATION | | | | TIMESTAMPING |
| GRAPHICS | | | +------------------+
|---------->|------------| | |
| | PIGCF L, U | <---| | +------------------+
+-----|------| | INTERPRETER| | | | RECEIVE |
| LANGUAGE | +------------+ | R | | MERGE TRAFFIC |<-
| BINDING | | PIGCF U |===> | O | <---| CHECK TIMESTAMPS |<-
+-----|------+ | GENERATOR | | U | | ERROR CORRECTION |<-
| +------------+ | T | | |
------------------| | E | +------------------+