Perform error checking often. Call glGetError() at least once each time the scene is rendered to make certain error conditions are noticed.

Do not count on the error behavior of an OpenGL implementation—it might change in a future release of OpenGL. For example, OpenGL 1.1 ignores matrix operations invoked between glBegin() and glEnd() commands, but a future version might not. Put another way, OpenGL error semantics may change between upward-compatible revisions.

If you need to collapse all geometry to a single plane, use the projection matrix. If the modelview matrix is used, OpenGL features that operate in eye coordinates (such as lighting and application-defined clipping planes) might fail.

Do not make extensive changes to a single matrix. For example, do not animate a rotation by continually calling glRotate*() with an incremental angle. Rather, use glLoadIdentity() to initialize the given matrix for each frame, then call glRotate*() with the desired complete angle for that frame.

Count on multiple passes through a rendering database to generate the same pixel fragments only if this behavior is guaranteed by the invariance rules established for a compliant OpenGL implementation. (See Appendix H for details on the invariance rules.) Otherwise, a different set of fragments might be generated.

Do not expect errors to be reported while a display list is being defined. The commands within a display list generate errors only when the list is executed.

Place the near frustum plane as far from the viewpoint as possible to optimize the operation of the depth buffer.

Call glFlush() to force all previous OpenGL commands to be executed. Do not count on glGet*() or glIs*() to flush the rendering stream. Query commands flush as much of the stream as is required to return valid data but don't guarantee completing all pending rendering commands.

Turn dithering off when rendering predithered images (for example, when glCopyPixels() is called).

Make use of the full range of the accumulation buffer. For example, if accumulating four images, scale each by one-quarter as it's accumulated.

If exact two-dimensional rasterization is desired, you must carefully specify both the orthographic projection and the vertices of primitives that are to be rasterized. The orthographic projection should be specified with integer coordinates, as shown in the following example:

gluOrtho2D(0, width, 0, height);

where width and height are the dimensions of the viewport. Given this projection matrix, polygon vertices and pixel image positions should be placed at integer coordinates to rasterize predictably. For example, glRecti(0, 0, 1, 1) reliably fills the lower left pixel of the viewport, and glRasterPos2i(0, 0) reliably positions an unzoomed image at the lower left of the viewport. Point vertices, line vertices, and bitmap positions should be placed at half-integer locations, however. For example, a line drawn from (x1, 0.5) to (x2, 0.5) will be reliably rendered along the bottom row of pixels into the viewport, and a point drawn at (0.5, 0.5) will reliably fill the same pixel as glRecti(0, 0, 1, 1).

An optimum compromise that allows all primitives to be specified at integer positions, while still ensuring predictable rasterization, is to translate x and y by 0.375, as shown in the following code fragment. Such a translation keeps polygon and pixel image edges safely away from the centers of pixels, while moving line vertices close enough to the pixel centers.

glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0, width, 0, height);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glTranslatef(0.375, 0.375, 0.0);
/* render all primitives at integer positions */

Avoid using negative w vertex coordinates and negative q texture coordinates. OpenGL might not clip such coordinates correctly and might make interpolation errors when shading primitives defined by such coordinates.

Do not assume the precision of operations, based upon the data type of parameters to OpenGL commands. For example, if you are using glRotated(), you should not assume that geometric processing pipeline operates with double-precision floating point. It is possible that the parameters to glRotated() are converted to a different data type before processing.

Use glColorMaterial() when only a single material property is being varied rapidly (at each vertex, for example). Use glMaterial() for infrequent changes, or when more than a single material property is being varied rapidly.

Use glLoadIdentity() to initialize a matrix, rather than loading your own copy of the identity matrix.

Use specific matrix calls such as glRotate*(), glTranslate*(), and glScale*() rather than composing your own rotation, translation, or scale matrices and calling glMultMatrix().

Use query functions when your application requires just a few state values for its own computations. If your application requires several state values from the same attribute group, use glPushAttrib() and glPopAttrib() to save and restore them.

Use display lists to encapsulate potentially expensive state changes.

Use display lists to encapsulate the rendering calls of rigid objects that will be drawn repeatedly.

Use texture objects to encapsulate texture data. Place all the glTexImage*() calls (including mipmaps) required to completely specify a texture and the associated glTexParameter*() calls (which set texture properties) into a texture object. Bind this texture object to select the texture.

If the situation allows it, use gl*TexSubImage() to replace all or part of an existing texture image rather than the more costly operations of deleting and creating an entire new image.

If your OpenGL implementation supports a high-performance working set of resident textures, try to make all your textures resident; that is, make them fit into the high-performance texture memory. If necessary, reduce the size or internal format resolution of your textures until they all fit into memory. If such a reduction creates intolerably fuzzy textured objects, you may give some textures lower priority, which will, when push comes to shove, leave them out of the working set.

Use evaluators even for simple surface tessellations to minimize network bandwidth in client-server environments.

Provide unit-length normals if it's possible to do so, and avoid the overhead of GL_NORMALIZE. Avoid using glScale*() when doing lighting because it almost always requires that GL_NORMALIZE be enabled.

Set glShadeModel() to GL_FLAT if smooth shading isn't required.

Use a single glClear() call per frame if possible. Do not use glClear() to clear small subregions of the buffers; use it only for complete or near-complete clears.

Use a single call to glBegin(GL_TRIANGLES) to draw multiple independent triangles rather than calling glBegin(GL_TRIANGLES) multiple times, or calling glBegin(GL_POLYGON). Even if only a single triangle is to be drawn, use GL_TRIANGLES rather than GL_POLYGON. Use a single call to glBegin(GL_QUADS) in the same manner rather than calling glBegin(GL_POLYGON) repeatedly. Likewise, use a single call to glBegin(GL_LINES) to draw multiple independent line segments rather than calling glBegin(GL_LINES) multiple times.

Some OpenGL implementations benefit from storing vertex data in vertex arrays. Use of vertex arrays reduces function call overhead. Some implementations can improve performance by batch processing or reusing processed vertices.

In general, use the vector forms of commands to pass precomputed data, and use the scalar forms of commands to pass values that are computed near call time.

Avoid making redundant mode changes, such as setting the color to the same value between each vertex of a flat-shaded polygon.

Be sure to disable expensive rasterization and per-fragment operations when drawing or copying images. OpenGL will even apply textures to pixel images if asked to!

Unless absolutely needed, avoid having different front and back polygon modes.

Use glXWaitGL() rather than glFinish() to force X rendering commands to follow GL rendering commands.

Likewise, use glXWaitX() rather than XSync() to force GL rendering commands to follow X rendering commands.

Be careful when using glXChooseVisual(), because boolean selections are matched exactly. Since some implementations won't export visuals with all combinations of boolean capabilities, you should call glXChooseVisual() several times with different boolean values before you give up. For example, if no single-buffered visual with the required characteristics is available, check for a double-buffered visual with the same capabilities. It might be available, and it's easy to use.