Implementing a Texture Manager

Environment: OpenGL

When programming a 3D engine that's supposed to render very big extensions (that's it: lots of geometry and lots of textures) that are going to be dynamically loaded from disk, we don't want to have lower framerates as we are transferring the data from disk to memory, and, especially while talking about textures, the API-specific calls to create the resources to handle the data can considerably decrease performance and produce non-desirable framerate changes.

Specifically, with OpenGL, calls to glTexImage() and glDeleteTextures() forces the OpenGL implementation to allocate/deallocate memory, and should be avoided as much as we can because calls to glTexSubImage() are way cheaper than the two others.

One way to do so is by implementing a texture manager, which can be done quite easily and can reduce the texture memory requirements as well as framerate changes. This way, every time we need memory to load a texture, the texture manager checks whether there's any texture with the same characteristics (size and format, which must be the same to reutilize the texture) which have been freed, and in case there's any, it can be used instead of generating another one.

So, what information must we have to know whether a texture can be loaded in another one? We can define a struct that looks similar to this one:

struct texObject
  int numDim;              //if the texture's 1d, 2d, or 3d
  int sizeU,sizeV,sizeW;   //size in the 3 axes
  int numMipLevels;        //number of mipmap levels it has
  void* pTextura;          //pointer to texture memory
  int creationFlag;        //return value which says us if we must
                           //create a texture or substitute it
  int numChannels;         //number of channels (rgb - rgba)
  int bytesPerPixel;       //2, 3, 4...
  unsigned int texName;    //texture object name to bind if it has
                           //already been created

  texObject();             //set default values

The interface the texture manager exposes should be something similar to this one:

void InitTextureManager();     //allocate memory and initialize
                               //as needed - implementation
void CloseTextureManager();    //free reserved memory
texObject* GetTextureMem(int numDim,int sizeU,int sizeV,int sizeW,
                         int numMipLevels,int numChannels,
                         int bytesPerPixel);
void ReleaseTextureMem(texObject* texture);

We could have two lists, one for freed textures and another one for used textures. They'll be called g_freeTextures and g_usedTextures from now on.

Basically, GetTextureMem(...) can be implemented this way:

texObject* GetTextureMem(int numDim,int sizeU,int sizeV,int sizeW,
                         int numMipLevels,int numChannels,
                         int bytesPerPixel)
  texObject* pTexObject;

  int totalSize= CALCULATE_BYTE_SIZE(numDim,sizeU,sizeV,sizeW,

  pTexObject= g_freeTextures.ExtractObject(numDim,sizeU,sizeV,

  if (pTexObject)
    //we've found a texture that fits what we need
    if ( pTexObject->texName )    //has OpenGL texture object
                                  //already been generated?
      pTexObject->creationFlag= MUST_CALL_GLSUB;
    else pTexObject->creationFlag= MUST_CALL_GLTEX;

    //we must create another texture
    pTexObject= new texObject;
    pTexObject->pTextura= new unsigned char[totalSize];
    pTexObject->creationFlag= MUST_CALL_GLTEX;
    pTexObject->numMipLevels= numMipLevels;
    pTexObject->sizeU= sizeU;
    pTexObject->sizeV= sizeV;
    pTexObject->sizeW= sizeW;
    pTexObject->bytesPerPixel= bytesPerPixel;
    pTexObject->numChannels= numChannels;


  return pTexObject;

The implementation of ReleaseTextureMem(...) could be as trivial as:

void ReleaseTextureMem(texObject* pTexObject)
  //we must take the texture object from the used-textures list
  //to the freed-textures list

That way, an object loader could ask for a texture this way:

texObject* pTexObject= GetTextureMem(int numDim,int sizeU,
                                     int sizeV,int sizeW,
                                     int numMipLevels,
                                     int numChannels,
                                     int bytesPerPixel);


//this could have to be done in a separate thread because of the
//openGL context


  m_pTexObject->creationFlag= TEX_OBJECT_INITED;


  m_pTexObject->creationFlag= TEX_OBJECT_INITED;

Of course, as we are having textures freed, it would be very handy to provide another function which would periodically free the textures that are in the free-texture list and have not been reused for a long time.


Download performance demo - 678 Kb

It compares performance between having textures created again and reusing them. Press 's' to switch the mode. To run the program, be sure you have DirectInput installed.


  • How about some benchmarking?

    Posted by Legacy on 06/27/2003 12:00am

    Originally posted by: Thanassis Anastassiou

    Very nice way of handling Textures...Although now you add the time to search a loaded textures database to find the apropriate texture and then replace it and so on.
    So in order to realy show, how nice this Texture manager is, you could provide some benchmarking....Framerate count in a classic rotating cube demo where textures would change rapidly and new ones would be loaded from disk.....

    Very nice work again.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • On-demand Event Event Date: September 23, 2015 The cloud is not just about a runtime platform for your projects – now, you can do your development in the cloud, too. Check out this webcast to learn how the cloud improves your development experience and team collaboration. Join Dana Singleterry, Principal Product Manager for Oracle Dev Tools, as he discusses how to simplify every aspect of the development lifecycle, including requirements gathering, version management, code reviews, build automation, and …

  • U.S. companies are desperately trying to recruit and hire skilled software engineers and developers, but there's simply not enough quality talent to go around. In response, companies often resort to inferior solutions -- hiring substandard developers and engineers, recruiting talent on a part-time or temporary basis, poaching people from competitors, or burdening an already stressed IT staff for more of their labor. Fortunately, there's a better solution. Read this white paper to learn the business value of …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date