🚀 go-pugleaf

Thanks for the well-considered reply.  It's worthwhile to bring
misunderstandings about PEX and OpenGL out into the open, and you've
helped to do that.

In article <1992Aug5.195634.9944@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:
 
| 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.

Yes, the original article stated this, and many people consider it one
of the major advantages of PEX.  Of course there's nothing to prevent
new APIs from being layered on OpenGL, just as they would be layered on
PEXlib or some other utilities to generate PEX protocol.  This has been
done with many APIs (including PHIGS) on IRIS GL, OpenGL's
predecessor.  Since OpenGL is at least as capable as IRIS GL in this
respect, and we know of third-party API ports to OpenGL already
underway, we don't feel that PEX actually has an advantage over OpenGL
in this area.

| > PEX 5.1 is missing functionality that is crucial for supporting it
| > [OpenGL].
| 
| 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.

I think the issue here is the goal of the PEX effort rather than the
participation of SGI.  "Supporting PHIGS efficiently" has always been a
goal of PEX; supporting "advanced" graphics functionality and GL have
not.  As an early member of the PEX team at DEC, I remember that
advanced functionality was proposed for PEX and then abandoned simply
because it was not necessary to support PHIGS.  The functionality
needed to support OpenGL is widely understood and could have been
included in PEX at any time, with or without SGI.  If PEX had been
intended from its inception to support a wide variety of APIs, I
believe this would have happened already.

| 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.

Yes, you've touched on a key point.  It deserves further clarification.

My first concern is for applications based on PEXlib.  PEXlib is often
advertised as an efficient, "thin-veneer" API for PEX in the same sense
Xlib is an API for the core X protocol.  Today PEXlib does not emulate
missing functionality.  To the extent that PEXlib continues to be a
thin veneer on the PEX protocol, and that applications use PEXlib,
applications are directly exposed to the difficulties of subsetting and
optional functionality.  This has already proven to be a problem for
ISVs, and the DEC and Kubota Pacific representatives at the last
PEX-Spec meeting made this point quite clearly.

My second concern is for API developers.  It costs time, dollars, and
engineers to develop comprehensive APIs like PHIGS in multiple versions
for the three PEX subsets.

To express the difference between PEX and OpenGL more clearly, I would
say that full functionality is guaranteed by OpenGL for both API and
wire protocol.  Full functionality is not guaranteed by the PEX wire
protocol, and is not supported by at least one very important PEX-based
API.

| 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.

Both OpenGL and PEX will continue to develop and certainly both will
acquire new functionality.  Both have technical and management
mechanisms for extensions.  But people who need to make a choice
between the two systems may well want to base their decision on the
functionality that's defined today, rather than what might be supported
a year or two from now.

| > 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.

This is a subtle but significant issue.  X11 servers provide support
for a limited number of "Visuals," which describe pixel formats and how
they're interpreted for display.  Not all Visuals are available on all
servers.  In particular, it's normal for 8-plane pseudocolor systems
(perhaps the most common type of X color display) to have no Visuals
for 24-bit true-color.  Therefore there is no way to use core X11 to
manipulate 24-bit RGB texture images on such systems.  Thus any
graphics package that wishes to support texture mapping must have some
independent mechanism for specifying texture images.  This is what PEX
lacks.

In the future, PEX implementations may use the services of the X
Imaging Extension (XIE) to handle textures.  This seems feasible only
if every implementation of PEX also ships with an implementation of
XIE.  And of course this may not be practical in window systems other
than X.

The point is that these problems are already solved in OpenGL.

| > 4.2.  Data Duplication
| > 
| > [...]
| 
| 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?

Rendering code must be specific to the API being used, granted.  But
that isn't the code I had in mind.  Instead, I was referring to the
guts of the application -- the code that manipulates its private data
structures and the graphics data in them.  If you have to change your
private data structures to make the graphics data acceptable to a
PEX-based API, then it's likely that application code outside the
renderer must be changed.  If you're not willing to change this code,
then you must extract the relevant data and reformat it or duplicate it
for rendering (thus paying the costs mentioned in the original paper).
This strategy has been observed in practice. :-)

| 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.

Not so, and this is a *very* important difference.  The OpenGL API
imposes essentially no restrictions on the format of graphics data --
there is no OpenGL data structure that defines a primitive, or even a
single vertex.  Graphics data may have virtually any data type, and
need not be stored in any particular order in memory.  If you're an
application developer porting existing code, you can invoke OpenGL
to draw the primitives stored in your data structures *without having
to modify or reformat those data structures.*

Furthermore, if a hardware vendor wishes to do so, it can assist the
OpenGL API with simple hardware that eliminates data copying and
preserves the contents of the CPU's data cache.  This is much, much
more difficult to do for PEX APIs -- I know because I've tried.  And as
Marty Hess (from the PEX team) mentioned twice at the SIGGRAPH debate,
bus bandwidth is a very critical and scarce resource in graphics
workstations.

| > 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.

The original text is referring to the local case, which is by far the
most common.  OpenGL can outperform PEX in the local case by
eliminating data reformatting and duplication, as described above.
OpenGL can also outperform PEX in the remote case for highly dynamic
databases, for display-list editing reasons described in the original
paper.  In the remote case with relatively static databases I suspect
the two graphics systems are on nearly equal footing, with the
implementation of display-list compilation being the deciding factor.

I agree with you that performance-sensitive applications still need to
distinguish between remote and local displays.  This is true for both
PEX and OpenGL.  It might be advisable to improve this situation in
next-generation graphics APIs.

Allen