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: February 11, 2015 @ 1:00 p.m. ET / 10:00 a.m. PT New computing platforms, expanding information environments, recurrent security breaches and evolving regulatory frameworks are factors that security executives must contend with and address when developing their security strategy. In response to these dynamics, security executives are seeking stronger, more nimble and more pervasive security technologies to help protect business-critical information from unauthorized disclosure, loss or …

  • In the words of epic book series Game of Thrones, "Winter is coming," and there's never been a better time to be on your guard. After all, we live in a world of vicious attacks, scary data breaches, unpredictable weather, and other factors that can threaten the very existence of both your applications and your precious data. Like any enterprise or organization, Westeros is endangered by a lack of continuity and poor disaster recovery plans. This white paper explores why disaster recovery should become a …

Most Popular Programming Stories

More for Developers

RSS Feeds

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