Table Of Contents
This guide contains the following chapters/sections.
ALL FILES INCLUDED HERE ARE COMPRESSED PostScript FILES
This chapter also briefly discusses fonts: "Using Fonts and Strings" looks at a simple example of using fonts with the glXUseFont() function.
Several extensions provide IRIS GL functionality that is not available in OpenGL 1.0. If you are porting a program from IRIS GL to OpenGL, you may therefore find some extensions particularly helpful. See Appendix A, "OpenGL and IRIS GL," for a list of IRIS GL commands and corresponding OpenGL functionality.
This chapter provides basic information about OpenGL extensions. You learn about:
This chapter explains how to use extensions to GLX. You learn about:
The following sections describe extensions that are experimental:
Note: Using OpenGL in an X Window System environment is discussed in the following chapters of this guide:
Writing high-performance code is usually more complex than just following a set of rules. Most often, it involves making trade-offs between special functions, quality, and performance for a particular application. For more information about the issues you need to consider, and for a tuning example, look at the following chapters in this book:
After reading these chapters, experiment with the different techniques described to help you decide where to make these trade-offs.
Note: If optimum performance is crucial, consider using the IRIS Performer rendering toolkit. See "Maximizing Performance With IRIS Performer".
Some points are also discussed in earlier chapters but repeated here because they result in particularly noticeable performance improvement on certain platforms.
Note: To determine your particular hardware configuration, execute /usr/gfx/gfxinfo. See the reference page for gfxinfo for more information. You can also call glGetString() with a GL_RENDERER argument. See the reference page for information about the renderer strings for different systems.
This appendix provides some additional information about porting IRIS GL to OpenGL, pointing to the extensions discussed in earlier chapters of this book where appropriate. In order to make it as short and comprehensible as possible, it won't repeat any information from the OpenGL Porting Guide.
For the OpenGL predecessor IRIS GL, you could call getgdesc() to determine whether a feature had hardware support. For example, you could determine whether a Z buffer existed. If it did, you might assume that Z buffering was fast, and therefore your application would use it.
In OpenGL, things are more complicated. All the core features are provided, even when there is no hardware support for them and they must be implemented completely in software. There is no OpenGL routine that reports whether a feature is implemented partly or completely in hardware.
Furthermore, features interact in unpredictable ways. For example, a machine might have hardware support for depth buffering, but only for some comparison functions. Or depth buffering might be fast only as long as stencilling is not enabled. Or depth buffering might be fast when drawing to a window, but slow when drawing to a pixmap. And so on. A routine that identifies hardware support for particular features is actually a lot more complicated and less useful than you might think.
To decide whether a given OpenGL feature is fast, you have to measure it. Since the performance of a section of graphics code is dependent on many pieces of information from the runtime environment, no other method is as well-defined and reliable.
Keep in mind that while the results of the libisfast routines are interesting, they apply to limited special cases. Always consider using a more general tool like Open Inventor or IRIS Performer.
Performance measurement can be tricky:
Libraries for Benchmarking
This appendix describes two libraries that can help with all of the tasks just mentioned:
These libraries can't substitute for comprehensive benchmarking and performance analysis, and don't replace more sophisticated tools (like IRIS Performer and IRIS Inventor) that optimize application performance in a variety of ways. However, they can handle simple tasks easily.