🚀 go-pugleaf

Based on the author's corporate affiliation, I hardly expected an
unbiased evaluation. Is this kind of rhetoric the legacy of the Reagan
era?

I will pass on opportunites to discuss PEX's merits, or discuss
changes to the protocol for 6.0, as I am no longer "up" on PEX. One of
the other PEX bigwigs can do that. But I hope I can clear up a few
misconceptions with this posting.

In article <1992Aug4.215142.6479@odin.corp.sgi.com>, bglazier@buffalo.asd.sgi.com (Bill Glazier) writes:
> [ ... ]
> 
> PEX does not specify an application programming interface. [ ... ]
> 
> The situation with OpenGL is much simpler. There is a single
> well-defined OpenGL API. [ ... ]

One could argue that PEX therefore allows the user the choice of any
API which has been ported to the PEX protocol, of which there are
currently several.

> In recent months some in the PEX community have advanced the view that
> the PEX protocol is a general-purpose foundation for supporting all 3D
> graphics APIs. IRIS GL is arguably the market-leading API for 3D, but
> PEX 5.1 is missing functionality that is crucial for supporting it.

This is because early on, SGI decided to not be a part of the PEX
effort, thereby giving up any hope that PEX would support their API.

> [ ... ] In contrast, it has been demonstrated that GL has
> sufficient functionality to support PHIGS because there are commercial
> PHIGS implementations built on IRIS GL.  Furthermore, IRIS GL has also
> been used to support higher-level APIs including IRIS Inventor, IRIS
> Explorer, and Ithaca Software's HOOPS. These examples lead us to
> believe that the GLX protocol is actually a better candidate than PEX
> to support a wide variety of APIs on an equal footing.

Wait, are we talking about GL here, or OpenGL? I thought this was a
comparison of OpenGL and PEX, so I don't see the relevance of what
software has been ported to use the GL API.

I certainly think it is a mistake to draw conclusions regarding PEX's
ability to support various software, based on what GL can support.

> 3.  Functionality
> 
> It is difficult to compare PEX and OpenGL functionality because of a
> major difference in design philosophy:
> 
> 	Nearly all PEX functionality is optional: it is not present in
> 	all PEX subsets, or some aspect of it is
> 	"implementation-dependent." The PHIGS API or PEXlib-based
> 	applications must query the PEX extension before using any
> 	implementation-dependent feature, and adjust their behavior
> 	accordingly. For example, a PEX implementation might include
> 	just the "PHIGS Workstation" subset, and thus be incapable of
> 	immediate-mode rendering.  Alternatively, it might include just
> 	the "Immediate Rendering" subset, and thus be incapable of
> 	anything else!  As another example, PEX provides an interface
> 	to select Phong shading, but there is no requirement that Phong
> 	shading actually be supported (and to our knowledge, no current
> 	implementations of PEX support it).  In short, it is not easy
> 	to say precisely what functionality PEX includes, because it
> 	varies so much from implementation to implementation.
> 
> 	In contrast, all OpenGL implementations are required to support
> 	all the functionality described in the specification. Even the
> 	advanced rendering features are guaranteed to be present.

OpenGL has two hats, "API" and "wire protocol". The "API" hat is being
used here, and that's dangerous when comparing to PEX.

Since PEX is a wire protocol, it will never be exposed directly to the
application programmer. It will always have an API wrapped around it.
Semantics for implementation of most any API, including OpenGL, have
restrictions on what must be supported. When you use that API, you are
guaranteed the functionality will be there.

An API running on a subset of PEX will emulate the missing
functionality in client-side software. This is the same thing OpenGL
does when running on machines which have little or no support in
hardware for its rendering features.

> [ ... ]
> 
> 3.4.  Feedback
> 
> OpenGL has provisions for tapping the graphics pipeline, so that the
> results of geometric transformations and lighting computations can be
> "fed back" to the application. PEX has no analogous capability.

What is not mentioned here (and in other places which claim "PEX has
no equivalent capability") is that PEX does provide extension
mechanisms to allow implementations to support these functions. A
given API would expose this support identically across platforms which
provide it heterogeneously.

> 3.6.  Image Operations
> 
> OpenGL includes routines to read, write, and copy pixels. These
> routines may be directed to the framebuffer or to bitmap data
> structures in the application. A number of operations including
> scaling, luminance transformations, and type conversion may be applied
> to the pixel data as it is moved. This functionality can be used to
> implement ordinary 2D raster operations, but is also used to render
> text and is needed to support image manipulation for texture mapping.
> 
> PEX has no support for image operations.

This is certainly an unfair comparison. Any PEX implementation is by
definition only available in an X environment, which provides a wide
variety of low-level 2D operations.

> [ ... ]
> 
> 4.2.  Data Duplication
> 
> There are two ways developers of PEX-based applications can avoid the
> dilemma described in the previous section. The first is to rewrite all
> data-structure-handling code so that the graphics data is stored in
> precisely the form required by PHIGS or PEXlib. In the extreme this
> involves dispensing with private data structures entirely, i.e. using
> PEX structure store for all graphics data and PEX structure extensions
> ("GSEs") for private non-graphics data. Not only would this force
> applications to be rewritten, but it would also require the use of
> interprocess (and sometimes network) communication to access the
> application database. [ ... ]

I don't see how this is any different from OpenGL. It doesn't matter
whether you are porting your code to a PEX-based API, or to OpenGL --
code will have to be rewritten in either case. Why do you imply that
porting to a PEX-based API alone will incur this overhead?

An application running on OpenGL is just as likely to be forced to
store its data in a format acceptable to OpenGL, as a PEX-based
application will be forced to store data in a format edible by PEX.
What is the problem here?

Furthermore, any application running in a networked environment will
try to store some graphical data on the display machine for reasons of
efficiency, thereby incurring interprocess communication overhead to
access the data. This is a feature of both PEX and OpenGL. PEX and
OpenGL both allow for client-side store as well. Nothing about PEX
"requires" the data to be stored on the display machine.

> The second approach is to duplicate the graphics data, keeping a copy
> in the proper form for a PEX API. This can be done by maintaining
> parallel data structures in the application or in PEX structure store.
> [ ... ]

Ditto for OpenGL in the case where the data is stored on the display
machine.

> OpenGL avoids all of these problems by making it unnecessary to
> duplicate or reformat graphics data.

Based on my points above I submit this statement is also true for PEX.

Anyway, out of time for now. Maybe more later. Thanks for the t-shirt,
Bill! Looks great! I'll let you know how it looks after I tie-dye it.
--

   -paul	pmartz@dsd.es.com
		Evans & Sutherland