Analysis of PEX 5.1 and OpenGL 1.0 Allen Akin Silicon Graphics Computer Systems August 3, 1992 1. Introduction PEX and OpenGL are two 3D graphics systems contending for the position of de facto standard in the workstation market. While they are similar in many ways, they also differ in important aspects of their application programming interfaces, functionality, performance, portability, openness, and responsiveness to changes in markets and in technology. To our knowledge, no detailed comparisons of PEX and OpenGL have been published. Perhaps this is because the two systems are evolving and few individuals have experience with both. With the release of PEX 5.1 and OpenGL 1.0, we believe the systems are relatively stable and it is now time to undertake a comparison. This paper analyzes some of the significant differences between PEX and OpenGL, with attention to issues faced by users as well as implementors. We hope it will be a positive contribution to the debate. 2. Programming Interfaces There is an essential difference in scope between PEX and OpenGL: OpenGL is an application programming interface. The OpenGL specification defines the data structures and procedure calls application programs must use to produce graphical output, as well as the semantics of the drawing process. PEX is a wire protocol. That is, PEX specifies how graphics requests are to be encoded (as if for transmission over a network), and what the semantics of those encoded requests must be. PEX does not specify an application programming interface. One of the primary goals of PEX is efficient support for PHIGS. The original PEX designers planned to use the ANSI and ISO programming language bindings for PHIGS, and they explicitly refused to define a competing API. Their decision was reflected in the name PEX, which is often said to be an acronym for PHIGS Extensions to X. This choice generated considerable controversy. Although PHIGS has the advantages of international standardization and an existing software base, it is quite complex and some software developers have claimed that using it would force them to restructure their applications. (For example, standard PHIGS lacks support for immediate-mode graphics.) As a result, many PEX proponents favor the use of a "PEXlib" which would expose the PEX protocol more completely. The X Consortium has proposed such an interface. It offers greater device-specific control and in many cases better performance than PHIGS. However, it also exposes PEX implementation dependencies (such as subsets) that must be handled by special-case code in applications rather than in the API. The deficiencies of PHIGS and PEXlib have led to proposals for additional PEX-compatible APIs. While supporting a variety of APIs improves the chance that at least one will be appropriate for any given application, the proliferation of interfaces has slowed the acceptance of PEX. Many hardware vendors and software developers have chosen to wait for one API to dominate, rather than risk investing in one that fails. The possibility that incompatible protocol changes in PEX 6.0 will force incompatible API changes in PEXlib has also caused concern. The situation with OpenGL is much simpler. There is a single well-defined OpenGL API. To guarantee interoperability in heterogeneous networks, there is an OpenGL extension (GLX) and wire protocol for use with the X Window System. In other environments (e.g. Microsoft Windows) where currently there is no need for a wire protocol, OpenGL has none. 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. (See below.) 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. 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. Despite this fundamental difficulty, some functionality comparisons can be made, and in such areas it is important to understand the differences between the two systems. Some examples follow. 3.1. Text PEX has extensive support for text, including a PEX font mechanism that is independent of X Window System fonts. (Access to X11 fonts is optional.) Ordinary PEX stroke-precision text is derived from a vector font, and is fully 3D-transformable. OpenGL provides routines that convert fonts from its environment (the X Window System or Microsoft Windows) into OpenGL display lists. The only font mechanism is that provided by the environment. If the original fonts are in outline form (e.g. TrueType), then the display lists will contain fully transformable geometry. If the original fonts are in bitmap form, then the display lists will contain bitmaps. PEX has the advantage that a fully transformable vector font is always available. OpenGL has the advantage that it guarantees all of the environment's existing fonts may be used, and there is no need to create, license, or distribute new fonts specifically for 3D. 3.2. Display List Editing Both PEX and OpenGL are used in networked environments, where it may be expensive to transport drawing requests from the client application to the graphics server. Both provide a server-side storage mechanism (called "display lists" in OpenGL, "structure store" in PEX) that allows applications to cache drawing requests on the server and avoid transport costs for requests that are reused. PEX supports nearly all of the PHIGS structure store editing functionality, including the ability to label sections of structures; insert, replace, or delete elements of structures; copy structures; and search through structures according to labels, hierarchical organization, or spatial position of the primitives in the structures. OpenGL display lists may only be created, replaced, and deleted. However, these operations can be performed on structures with very fine granularity. For example, in OpenGL it is possible to create display lists containing the data for independent vertices of a polygon, and to define the polygon as a set of calls to those display lists. A given vertex of the polygon may then be "edited" by replacing its display list. This is not possible in PEX; individual vertices cannot be edited, and primitives must be replaced in their entirety. (See Performance below for some consequences of this difference.) 3.3. Complex Polygons Both OpenGL and PEX support single- and multi-contour polygons with convex and nonconvex shapes. PEX supports self-intersecting contours and polygon lists with shared geometry, while OpenGL does not. 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. 3.5. Alpha Blending OpenGL supports an alpha (coverage) buffer and an explicit alpha component in colors. These are used for antialiasing and image composition. PEX does not support alpha blending. 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. 3.7. Texture and Environment Mapping OpenGL includes a complete implementation of texture mapping. The application controls the exchange of rendering time for image quality, and it may use its own texture prefiltering if that provided by OpenGL is inadequate. Texture coordinates may be specified explicitly or generated automatically, and they may be transformed by an arbitrary 4x4 matrix. Textures may be applied to a surface as if they were decals, or they may be blended with the surface in a number of ways. PEX has no equivalent capability. 3.8. Antialiasing PEX has no official support for antialiasing. Some implementations have provided it as a nonstandard extension. OpenGL has explicit support for antialiasing points, lines, and polygons. In addition, the accumulation buffer may be used to implement full-scene antialiasing. 3.9. Progressive Refinement The OpenGL accumulation buffer permits straightforward implementation of progressive refinement, the gradual improvement of image quality over a period of time. PEX has no equivalent. 3.10. Capping Planes OpenGL supports a multipass capping-plane algorithm using its stencil buffer and other auxiliary buffers. PEX as currently defined cannot support this functionality. 3.11. Constructive Solid Geometry The OpenGL stencil, accumulation, and auxiliary buffers can be used to render objects defined by the regularized Boolean operations of constructive solid geometry. PEX does not have this ability. 3.12. Motion Blur The OpenGL accumulation buffer can be used to simulate motion blur. PEX has no support for it. 3.13. Depth-of-Field With appropriate change in viewing parameters, the OpenGL accumulation buffer can be used to produce an image with finite depth-of-field. This function is not available in PEX. 4. Performance Interactive 3D graphics demands much higher performance than 2D graphics, and therefore affects more aspects of system design. The architecture of a successful 3D graphics system must encompass not only 3D transformations, shading, and scan conversion, but also CPU load, cache behavior, main memory bandwidth requirements, main memory capacity requirements, bus transaction latency and throughput, address translation costs, and graphics processor request queueing, among other things. These issues must be considered for the graphics software, operating system, window system, and even the applications programs. There are numerous existence proofs that both PEX and OpenGL can support high-performance implementations. However, the two systems do not place equal emphasis on some of the design issues mentioned above. We believe that these differences in design would lead to differences in performance should PEX and OpenGL be implemented on the same hardware, and we believe that trends in semiconductor technology will tend to widen the performance gap. 4.1. Data Reformatting It is nearly always necessary for applications to maintain private data structures that are specialized for their particular problem domains. Graphics data is just one component of these structures. Current PEX APIs (and the PEX protocol) use their own data structures for describing graphics primitives. For example, a polygon consists of a counted list of vertices, each of which contains coordinates in floating-point format, plus optional data such as colors and surface normals. When an application wishes to make an immediate-mode graphics request, it must extract data from its private data structures, reformat it to match the PEX interface requirements, write it to a temporary buffer, and then invoke the PEX API to process it. This has several consequences: The CPU must spend cycles to reformat and copy the data. These cycles do no useful work, yet they are lost to the application and to other processes in the system that might have made use of them. Furthermore, since they are in application code outside the scope of the graphics system, no improvement in the graphics hardware or software can recover the loss. For high-performance interactive 3D graphics applications, where a considerable amount of data must be processed for each frame, the reformatting process sweeps the system's data cache repeatedly. This can drastically reduce the effectiveness of the cache, and thus degrade performance for the entire workstation. During reformatting, the CPU is generating memory transactions at a high rate. The bus traffic resulting from these transactions interferes with other users of the system bus. One critical user of the bus that may be adversely affected by this traffic is the graphics processor. To quantify this problem, consider a hypothetical workstation (simplified, but similar to many in use today). It has a 32-byte cache line, a 64-bit-wide bus to memory, and main memory with a 240ns random-access cycle time and an 80ns page-mode-access cycle time. A cache line occupies four sequential addresses, so it can be read in (240ns + 80ns + 80ns + 80ns), or 480ns. We'll ignore the cost of reformatting. Writing the cache line to memory takes another 480ns. Therefore we can copy 32 bytes in a total of 960ns, for an average copy rate of 33MB/s. An independent 3D triangle is composed of three vertices, each having three coordinates, three color components, and three surface normal components. If all of these are specified by single-precision floating-point values, then the total size of the triangle is 108 bytes. Therefore our 33MB/s copy rate is sufficient to copy a little more than 300K triangles per second. At this rate, our workstation is completely saturated by the data reformatting process; there is no time for drawing the triangles, much less running the application. This maximum performance level is already below the target drawing rate for comparable machines that exist today. And any additional reformatting or copying (for example, to build PEX protocol packets) reduces the maximum drawing rate still further. OpenGL uses a different approach. The OpenGL API allows graphics data to be extracted directly from the application's private data structures, without reformatting. It is also possible to support this interface in hardware in such a way that the data need never be transferred into the CPU, so it will not sweep the CPU's cache. This is impractical for PEX on the hardware with which we are familiar. For years, CPU cycle times have improved more rapidly than main memory cycle times. We expect this trend to continue, with the result that PHIGS and PEXlib-style APIs (as well as any new PEX APIs that reformat data to build PEX protocol packets) will become increasingly limited by memory access. Since so many cycles will be spent copying data, systems based on PEX will need to be faster and more expensive to sustain the same overall level of application performance as systems based on OpenGL. 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. In any case, eliminating the application's specialized data structures is usually not feasible, since those structures are instrumental in providing the added value that makes the application successful commercially. 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. In practice, we have found that these methods rarely work. In the case where the graphics data is static, and well-separated from other application data, maintaining a parallel graphics database can be effective. Usually, though, the graphics data is being referenced frequently, is edited, or is intermixed with other data. In such cases maintaining parallel data structures causes the real memory requirements of the application to expand dramatically. Typical CAD/CAM graphics databases are 20MB-40MB in size today, and are expected to grow. Customers are reluctant to purchase that much real memory to add to their systems, especially if they know that it is only being used for duplicated data! Applications developers are reluctant to add the code needed to keep the duplicated data in sync with the main database. OpenGL avoids all of these problems by making it unnecessary to duplicate or reformat graphics data. 4.3. Display Lists Once a PEX structure is created, it may be edited by inserting or deleting new structure elements. Once an OpenGL display list is created, it may only be deleted or replaced; it may not be edited. OpenGL makes this restriction to allow its display lists to be "compiled" into a more efficient form at the time they are created. This is particularly effective for entities like texture maps and material definitions that may involve a significant amount of preprocessing. It can also be used to perform data type and format conversions, or to move drawing requests into special display list memory for fast access by the graphics hardware. PEX structures may be compiled, too. However, because they are editable, a number of complications arise. For example, since there is no provision in PEX for "opening" and "closing" a structure, the PEX extension cannot determine when edits to a structure are complete. Recompiling a structure after each edit could be a great waste of time, since another edit might arrive shortly thereafter. To avoid this, recompilation must be delayed until the structure is actually invoked. This increases implementation complexity and on systems with graphics accelerator hardware it can increase overhead in the "fast path" case for drawing. Another issue arises when a PEX structure is in main memory, and the graphics hardware accesses it by DMA. Since a given structure may be read by the graphics hardware and written by the structure editor at the same time, access to it must be interlocked. This interlock must be fairly fine-grained; one cannot simply lock out edits until structure traversal is completed, because the PHIGS model for graphics requires support for continuous traversal and "pending" edits. Usually the structures being changed are precisely those that need to be accessed by the graphics hardware to update the display, so conflicts are frequent. Furthermore the required locks are interprocessor locks, so they are expensive on many machines. On a machine with a similar architecture, OpenGL display lists would also require interlocks. However, the interlocks are needed for just three operations (display list replacement and deletion must be interlocked with display list lookup), and continuous traversal is not an issue. Fewer synchronization operations are needed than for PEX, and the critical sections complete more quickly (often in a single instruction). 4.4. Display List Editing Granularity PEX structures are edited by inserting, deleting, or replacing "structure elements," which consist of geometric primitives or attribute-setting commands. Thus PEX structure editing can be applied to individual primitives, but not to any entity at a finer granularity. This can cause performance problems when editing large primitives. For example, to change the location of one vertex in a large quadrilateral mesh, the entire mesh must be re-transmitted to the server. In many cases this eliminates the advantage of PEX structure store. As noted above in Functionality, OpenGL display lists may invoke other display lists even within a single primitive. Although display lists may not be edited, they may be replaced. Together these two features allow primitives to be edited at a very fine granularity. For example, a quadrilateral mesh can be defined as a set of calls to display lists that define its individual vertices. Replacing the display list for a vertex effects a vertex-level edit. Only the data for the new vertex need be transmitted to the server. 4.5. State Save and Restore PEX semantics require that all rendering pipeline attributes be saved when a structure is traversed, and restored when the traversal is completed. This demands an expensive "push and pop" of the complete state, or a complex copy-on-write scheme that adds cost to attribute-setting commands. OpenGL state is saved and restored selectively, and only when the client application requests it, so the process can be optimized or even eliminated if it is not needed. 4.6. Indirect Attributes In PEX, attributes like the color and style of a primitive may be stored in "bundles." A flag associated with each primitive determines whether that primitive's attributes are provided directly (along with the geometry for the primitive) or indirectly (from a bundle). In immediate-mode drawing the flag must be tested, and that slows down the fast drawing path for the primitive. In both immediate and structure modes, the use of the bundle forces a memory access to a nonsequential address, which often causes a TLB miss or a random-access penalty for the memory subsystem. Since the bundle tables may be large, they cannot always be stored on the graphics subsystem; this makes it difficult to optimize the graphics pipeline for some important cases (like polygons, where the style of the primitive has a substantial effect on the computations needed to display it). OpenGL pushes attribute lookup back to the level of the application, so the cost of indirection is incurred only when it is strictly necessary. The display list mechanism can be used to implement attribute indirection straightforwardly, for arbitrary sets of attributes. 5. Portability The single most important reason to standardize a graphics system is to guarantee portability for the applications that are based on it. PEX and OpenGL may well succeed or fail depending on how effectively their APIs and wire protocols support this goal. 5.1. Subsetting PEX has three mutually-incompatible subsets: immediate-mode, structure-mode, and "PHIGS Workstation." Vendors of PHIGS for PEX must provide three significantly different implementations layered on these subsets to insure network transparency and application portability. A single PEXlib is sufficient to support all three subsets, but at the cost of pushing portability issues all the way up into the application. Real software portability does not yet exist in the PEX world because of the wide variations in commercial versions of PEX. The existence of these PEX subsets may be indicative of the difficulty of building a full PEX implementation. If true, this has negative implications for the quality, availability, and timeliness of PEX. In order to combat application portability problems caused by subsetting and optional functionality, a group of PEX vendors has found it desirable to fund a private organization, the PEX Interoperability Center, just to provide a PEX porting and testing environment. OpenGL may not be subsetted. Application developers can be assured that all OpenGL features will be available on all implementations. Unlike PEX today, there exists an OpenGL sample implementation with complete functionality. The need for interoperability testing is greatly reduced because OpenGL implementations are much more consistent than PEX implementations. 5.2. Optional Functionality Many of the features described in the PEX protocol specification are optional. For example, the protocol contains provisions for scanline rendering, Phong shading, and CIE LUV color computations, but none of these features is guaranteed to be available in any particular PEX implementation. To use any optional feature, an application must query the server to determine if the feature is available. If not, the application must include code for a fallback strategy. This approach is very general, but it yields portable programs only by imposing a large burden on every application developer. In contrast, OpenGL has a much larger set of core features that are universally supported. 5.3. Conformance Testing To our knowledge, there are no comprehensive test suites available to validate PEX implementations. This makes it difficult to determine whether a particular implementation conforms to the specification. It also reduces confidence that an application that runs on one implementation of PEX will also run correctly on another. A suite of conformance tests for OpenGL 1.0 ships with every release kit. 5.4. Window-System Dependency PEX as it is defined today is very closely coupled to the X Window System. The semantics of X resources, drawables, atomicity/sequentiality requirements, and events are integral to the design of PEX. However, there are other commercially-significant window systems. Microsoft Windows is an example. In order to accommodate these systems, OpenGL separates the parts of the interface that are window-system dependent (about ten routines under X11) from those that are window-system independent. Adding a small new set of window-system dependent routines allows the remainder of OpenGL to be used without change. This capability is being exploited to port OpenGL to Microsoft Windows/NT, with the expectation that Windows/NT platforms will offer a large new market for 3D graphics applications. 6. Business Issues Although the primary focus of this paper is on the technical differences between PEX and OpenGL, it is also necessary to consider the most critical business issues: licensing, processes for changing the systems, market acceptance, and availability. 6.1. Licensing The PEX specifications and sample implementation are available as part of the X11 distribution, at no additional fee. Vendors may release their commercial-quality implementations of PEX as bundled or layered products without royalty. To cover costs, the members of the X Consortium make direct financial contributions for support of X and PEX; for example, the PEX Sample Implementation cost contributors a total of roughly $750K. Anyone can license OpenGL from Silicon Graphics at nominal prices. Manual pages are available by anonymous ftp at no cost. A Level 1 license (including the OpenGL specifications, manual pages, C bindings, GLU utilities, demo applications, compliance suite, and the right to redistribute an implementation) is $25K. A Level 2 license (all of Level 1 plus reference implementation, optimized portable sample implementation, X11 server extension, and porting documentation) is $100K. (This was chosen to be less than the fully-burdened cost of one engineer for a year.) A university license is available for $500. There is a royalty of $5 per revenue copy. These fees allow SGI to recover expenses for distribution and maintenance of OpenGL, in much the same way consortium membership fees allow the X Consortium to provide maintenance for PEX. 6.2. Mechanisms for Change In the case of PEX, multiple independent entities (ANSI, ISO, the PHIGS-PLUS committee, and the X Consortium) are responsible for defining various parts of the APIs, rendering semantics, and wire protocol. This has led to some problems of timeliness and compatibility, particularly with respect to PEX support for PHIGS- PLUS. It has also contributed to the proliferation of PEX APIs. However, the process is open to essentially anyone. A single organization (Silicon Graphics) defined the original specification for OpenGL, and a single entity (the OpenGL Architecture Review Board) is now responsible for all aspects of the API and wire protocol. The bylaws ensure that each of the six companies on the ARB has an equal vote on all API and governance issues. All decisions require a two-thirds majority vote. Compared to the organization used by PEX, we believe this structure will be more responsive to the needs of OpenGL users and more likely to maintain the technical integrity of the design as it evolves. SGI has full-time engineering resources assigned to implement the decisions of the OpenGL ARB. This allows new code to be written and tested quickly, and thus brought to market earlier or with more user-requested features. The X Consortium funds two full-time positions for PEX; other development work is provided by sponsoring companies on a volunteer basis. 6.3. Vendor Support Presently we know of five commercial-quality PEX products. Twenty companies are participating in the PEX Interoperability Center in Dallas, Texas, and therefore many should be expected to release commercial PEX products sometime in the next year. Today SGI, IBM, Nth Graphics, and DuPont Pixel Systems are shipping products compatible with IRIS GL, the predecessor to OpenGL. Twenty personal computer and workstation companies have licensed OpenGL, and commercial implementations will be available sometime in the next year. A considerable number of vendors have stated their intent to support both PEX and OpenGL. The most compelling difference in vendor support is the endorsement of OpenGL by Microsoft and Intel. The OpenGL API will be bundled with future versions of Microsoft's Windows/NT environment, providing appli- cations based on OpenGL with a personal computer market at least an order of magnitude larger than the workstation arena. 6.4. Software Applications Base PEX per se has a small base of applications, because it has not been widely available until recently. The existing base of PHIGS code, much of which is found in CAD/CAM, government, and European markets, has a logical porting path to PEX. PEXlib is an alternate API for developers who find PHIGS inappropriate, but it requires substantial recoding because it is essentially a new API. There is some concern that ISVs will delay ports to PEXlib, because the PEX designers have chosen to make incompatible changes to the protocol for the next PEX release, and this could force incompatible changes to the PEXlib interface. IRIS GL has the majority of applications in markets requiring high-performance 3D graphics - CAD/CAM (particularly finite element and structural analyses), animation, creative graphics, visual simulation, and scientific visualization. Since OpenGL is not backward-compatible with IRIS GL, existing IRIS GL applications must be ported. The majority of the current base of 1500 IRIS GL applications are expected to port to OpenGL, given its similarity to IRIS GL, the need to stay current with SGI and its product release schedule, and the wider mar- ket that is provided by OpenGL. According to a poll taken at the last SGI Developers Conference, 85% of the current IRIS GL ISVs have already decided to port to OpenGL. Because OpenGL evolved from IRIS GL, much of the conversion process can be automated; SGI demonstration programs were ported at the rate of 5000 lines per engineer-day. SGI has a vested interest in simplifying the move from IRIS GL to OpenGL, because OpenGL is the native interface for future SGI hardware. 6.5. Availability The PEX 5.1 specification review process will be complete very shortly, and we can expect PEX 5.1 implementations to be available in the Fall of 1992. The OpenGL 1.0 specification and sample implementation shipped on June 30, 1992. The first commercial implementations are expected in the first quarter of 1993. The PEX design committee has chosen to make the next update of PEX incompatible with previous versions. The specification for PEX 6.0 will include some of the advanced rendering features of OpenGL, and should be complete near the middle of 1993. First implementations could appear as early as 1994. 7. Conclusions We believe diversity in computer graphics interfaces can be desirable if it encourages real innovation in hardware, system software, and applications. However, if the computer graphics community feels it must standardize on one graphics system, OpenGL is a better choice than PEX: OpenGL has a single well-defined API. There are two major competing APIs for PEX, and one of them (PHIGS) is not under the control of the organization defining PEX. OpenGL has more rendering functionality than PEX. In addition, more OpenGL functionality is guaranteed to be present in all implementations than is the case for PEX. When the entire computing system is analyzed, OpenGL has several important performance advantages over PEX. These advantages apply to both immediate-mode and structure-mode rendering. OpenGL applications can be made portable with less effort than is needed for applications based on PEX, because OpenGL implementations are more consistent functionally and are subject to validation by a conformance test. OpenGL is also less dependent on the window system under which it is run. Both OpenGL and PEX are available on generous terms, and both have a good deal of support in the industry. The X Consortium process for defining PEX is more democratic and participatory, but OpenGL's governance process will likely result in better technology coming to market more quickly. Both systems offer porting paths from existing code bases: from stand-alone PHIGS to PHIGS on PEX, and from IRIS GL to OpenGL. However, the initial OpenGL application base will be substantially larger. OpenGL will be a standard part of Microsoft Windows/NT. This provides OpenGL applications a vastly larger potential market than is available to PEX applications, and will make OpenGL more attractive to independent software developers. We welcome your comments and suggestions. References Goldfeather, Jack, et. al., "Fast Constructive Solid Geometry Display in the Pixel-Powers Graphics System", Computer Graphics 20:4 (SIGGRAPH 1986 Conference Proceedings), August, 1986, pp. 107-116. Haeberli, Paul, and Akeley, Kurt, "The Accumulation Buffer: Hardware Support for High Quality Rendering," Computer Graphics 24:4 (SIGGRAPH 1990 Conference Proceedings), August, 1990, pp. 309-318. Mammen, Abraham, "Transparency and Antialiasing Algorithms Implemented with the Virtual Pixel Maps Technique," IEEE Computer Graphics and Applications, July, 1989. Segal, Mark, and Akeley, Kurt, The OpenGL Graphics System: A Specification (Version 1.0), June 30, 1992, Silicon Graphics, Inc. Womack, Paula (ed.), PEX Protocol Specification Version 5.1P - X Public Review Draft, May 11, 1992, Massachusetts Institute of Technology. The Author Allen Akin is an Engineering Manager in the OpenGL group at Silicon Graphics. He is currently integrating OpenGL with Microsoft Windows/NT. His graphics experience includes a year at MacroMedia, where he completed the MacroMind Three-D animation system for the Apple Macintosh, and five years at Digital Equipment Corporation, where he served as Engineering Manager for the first commercial implementation of PEX and as Graphics Software Architect for RISC workstations. He can be reached at the Internet address akin@sgi.com. Copyright 1992, Silicon Graphics, Inc. All rights reserved.