🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sgi.general
Article #12

Re: Analysis of PEX 5.1 and OpenGL 1.0

#12
From: Allen Akin
Date: Thu, 06 Aug 1992 19:38
50 lines
3178 bytes
In article <1992Aug6.173023.3987@dsd.es.com> pmartz@dsd.es.com (Paul Martz) writes:
| Good reply, Allen. I see your point on several issues now. Except for...
| 
| [...]
|
| Well, I hear PEXlib more often advertised as an SPI -- systems
| programmer interface, not intended for use by applications.
| Applications which directly use PEXlib should know what they are
| getting themselves into.

This is one of the reasons there were objections to releasing a PEXlib
in the early days of PEX.  Rightly or wrongly, many ISVs and even
end-users now have the perception that PEXlib gives them better
performance, control, or more timely access to new functionality than
most commercial implementations of PHIGS.  This results in a belief
that apps are at a competitive disadvantage if they don't use PEXlib.
As the X Consortium formalizes PEXlib, and as the ISVs choose to base
their apps on it, PEXlib is gradually pushed out of its SPI status into
the limelight as an API.  I suspect that ISVs and in-house developers
who use PEXlib may not realize the extent to which they're exposing
themselves to subsetting, optional-functionality, and protocol upgrade
issues.

As an aside, there's a performance concern related to the use of PEXlib
as an SPI.  If the data format of the API layered on it doesn't match
PEXlib's, then data reformatting overhead is incurred.  That can cause
bus bandwidth bottlenecks for applications that use immediate-mode or
perform frequent display-list edits.  The original paper contained a
sample bus bandwidth calculation that illustrates the effect.

|                           ... X and PEX have never claimed to be the
| be all and end all of imaging. It is beyond the scope of both, and
| falls completely into the realm of XIE. Saying "PEX doesn't provide
| support for imaging and OpenGL does" is like saying "the Jeep can go
| offroad but the Corvette can't". A useful comparison, if you want to
| drive offroad, but an apples and oranges comparison nonetheless.

I understand your objection now.  The analysis paper would have been
clearer if I had made the connection between image operations and
texture mapping more explicit.

Imaging support of some kind becomes mandatory once texture mapping is
available.  As long as PEX doesn't support texture mapping, it doesn't
need much imaging support.  If PEX is extended to include texture
mapping, then it will need access to image operations.  The OpenGL
designers just chose to incorporate the necessary functionality in the
OpenGL API rather than depend on an external source.  This is partly
due to the need for window-system independence.

Allen
Technical Details
Message-ID: <o88ou9g@fido.asd.sgi.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!dtix!darwin.sura.net!mips!odin!fido!akin
References: <1992Aug5.195634.9944@dsd.es.com> <o75njjk@fido.asd.sgi.com> <1992Aug6.173023.3987@dsd.es.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!dtix!darwin.sura.net!mips!odin!fido!akin
From: akin@sgi.com (Allen Akin)
Newsgroups: sgi.general,comp.sys.sgi,comp.graphics,comp.windows.x.pex
Subject: Re: Analysis of PEX 5.1 and OpenGL 1.0
Message-ID: <o88ou9g@fido.asd.sgi.com>
Date: 6 Aug 92 19:38:35 GMT
References: <1992Aug5.195634.9944@dsd.es.com> <o75njjk@fido.asd.sgi.com> <1992Aug6.173023.3987@dsd.es.com>
Sender: news@fido.asd.sgi.com (Usenet News Admin)
Organization: Silicon Graphics, Inc.
Lines: 50