Article View: sgi.general
Article #12Re: Analysis of PEX 5.1 and OpenGL 1.0
From: Allen Akin
Date: Thu, 06 Aug 1992 19:38
Date: Thu, 06 Aug 1992 19:38
50 lines
3178 bytes
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!akinReferences:
<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