PEX 5.0 Interoperability Addendum
Version 1.0
Greg Stiehl
April 24, 1992
1) Each X Consortium vendor wishing to define their own OC types,
enum types, enum values, table types, or GDP/GSE ids will be given
a unique vendor id (a number) by the MIT registry.
2) Vendor id numbers will range from 1 to 126. The numbers 0 and 127
are reserved and will not be distributed.
3) If all vendor id numbers are distributed, a new vendor wishing
a number will have to negotiate with an existing registered
vendor and share that number space; otherwise, the new vendor
will have to wait until PEX 6.0 when the vendor id space
will be expanded.
4) A vendor specific OC type, table type, enum type, or enum value
will have the high bit set (bit 15) and the vendor id encoded in
the high bits (bits 14 through 8) of the type or value:
Bit 15 a one
Bits 14..8 a unique vendor number
Bits 7..0 the type or value
5) A vendor specific GSE/GDP ids
will have the high bit set (bit 31) and the vendor id encoded in
the high bits (bits 30 through 16) of the GSE/GDP id:
Bit 31 a one
Bits 30..16 a unique vendor number
Bits 15..0 the id
6) All vender specific OC types, table types, enum types, enum values,
and GSE/GDP ids can be queried by GetEnumeratedType. Since the
GetEnumerateType interface is only 16 bits, GSE/GDP ids will be
packed into 16 bits. Therefore all types, values and ids are
encoded:
Bit 15 a one
Bits 14..8 a unique vendor number
Bits 7..0 a type, value, or id
7) Since less information can be stored when returning GDP/GSE
ids through GetEnumeratedType, it is possible to have ids that
are the same. In this case, the mnemonics will have to be
use to distinguish between the two. Because of this problem,
it is recommend that venders tightly pack their ids so as not
to exceed 8 bits of significance.
8) Defining a separate X extension is the only way to add
requests, events, or errors to PEX. XQueryExtension can
be used to determine the base offsets for any new requests,
errors, or events.
9) Rather than adding a new PEX request to determine which
extensions to PEX are supported, the standard XListExtensions
request should be used.
10) Large requests (those greater than the maximum request size)
will be passed to the server using a general X extension
mechanism TBD. Individual OC's will still be limited
to 64K words.
11) OCNil is encoded as 0xFFFF (This is the current PEX-SI OC
value, and would conform to the encoding specified, if PEX-SI
had vendor id 127: 0xFFFF = [1,vendor 127,value 255]).
12) If facet normals are not given, the server should compute
them as described in the PHIGS-PLUS (DP) Document (ISO/IEC 9592-4,
February 14, 1991 draft, page 39, clause 4.5.5.3, Reflection
Normals). The server should not modify any normals that the
client explicitly defines.
13) The direction vector associated with the WCS_Vector and
WCS_Spot light types points in the direction the light would
travel from these sources.
14) Specular exponents are used as specified in Annex C of the
PHIGS-PLUS (DP) Document (ISO/IEC 9592-4, February 14, 1991
draft).
15) Not all server support all drawables. The only drawable
type that can be assumed is Window. In a future release
of PEX, a routine will be provided for checking for support
of each drawable type.
16) To double buffer while using the Workstation subset, the
Workstation should be created using the Double Buffer
Workstation type.
==8<==8<==8<==8<==8<==8<==8<==8<== CUT HERE ==>8==>8==>8==>8==>8==>8==>8==>8=
New items to be considered:
17) 5.1 servers will return their list of supported rendering targets
in the order of descreasing "goodness" for PEX rendering, i.e.
the first target in the list should be the best target for PEX.
18) 5.0 and 5.1 servers will return their native floating point format
as the first entry in the list of supported floating point formats
returned by PEXGetEnumeratedTypeInfo.
19) Implementations which do not support the pattern interior style will
not guarantee support for the pattern lookup table (a LookupTable
error will be returned from PEXCreateLookupTable).
20) Implementations will return a Value error from PEXCreateLookupTable
for attempted creation of vendor specific lookup tables which are
not supported.
21) 5.0 servers will return a Match error from PEXBeginRendering with a
drawable of a type not supported for PEX rendering.
22) There is an issue about color approximation constraints - are they
allowed, and if so, how does the client determine what is supported?
HP proposed the following:
Predefined Color Approximation Table Entries
Implementations that support only a limited set of color approximation
configurations, which may vary by target, should support a predefined entry in
the color approximation table for each of the supported configurations. All the
PEXColorSpace entries should appear first in the set of predefined entries
(i.e., at lower indices in the range of predefined indices), ordered from best
overall behavior (image quality and performance, in the implementation vendor's
judgment) to worst. If the implementation also has limited support for
PEXColorRange, those predefined entries should follow the PEXColorSpace entries,
again ordered from best to worst.
Implementations that support arbitrary color approximation should define no
predefined color approximation entries.
This convention allows clients to use PEXGetPredefinedEntries (which requires an
example drawable) to inquire the color approximation support in a
target-specific manner. If an implementation in fact has limited color
approximation support, but does not support this convention, the client will
assume it has unlimited support, just as it would if the convention did not
exist.
--
Jas