Where's the Beef?

Running either of these two examples, you may doubt that you are actually getting any hardware acceleration at all. One of the original OpenGL designers once admitted to me that he thought the omission of texture objects was one of the major (but few) blunders of OpenGL 1.0. (This blunder was fixed with 1.1, which is why you’'re reading this.) At the time, OpenGL's engineers thought that display lists would do an adequate job of encapsulating the texture loads. The purpose of a display list is to encapsulate a group of OpenGL commands into a preprocessed batch that can be sent to hardware quickly or even invoked remotely via a client/server interface. While display lists are great for precompiling a set of OpenGL commands into hardware commands, they can be very difficult for hardware vendors to optimize when they contain important state changes, such as loading a new texture.

Loading a texture can be quite time consuming, especially if the native format is different from what you’'re specifying (such as using a 24-bit texture image when the driver converts it to a 16-bit image internally). Thus, even though using a display list can save a great deal of intermediary calculations (or disk accesses), some time is always lost due to the actual texture upload. What we need is a way of keeping this internal texture data around for individual textures. We can then reference these textures individually instead of performing multiple texture loads. This is exactly what texture objects do.