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

  • Live Event Date: December 11, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Market pressures to move more quickly and develop innovative applications are forcing organizations to rethink how they develop and release applications. The combination of public clouds and physical back-end infrastructures are a means to get applications out faster. However, these hybrid solutions complicate DevOps adoption, with application delivery pipelines that span across complex hybrid cloud and non-cloud environments. Check out this …

  • VMware vCloud® Government Service provided by Carpathia® is an enterprise-class hybrid cloud service that delivers the tried and tested VMware capabilities widely used by government organizations today, with the added security and compliance assurance of FedRAMP authorization. The hybrid cloud is becoming more and more prevalent – in fact, nearly three-fourths of large enterprises expect to have hybrid deployments by 2015, according to a recent Gartner analyst report. Learn about the benefits of …

Most Popular Programming Stories

More for Developers

RSS Feeds