DemoGL::About::The Texturestore

The Texturestore.

DemoGL contains a basic texture management system called The Texturestore. Most OpenGL based applications use textures and because working with textures can be cumbersome when it comes to OpenGL, DemoGL offers a simple but powerful texture manangement system.

Textures inside DemoGL are stored in textureobjects and have several properties like width, height, depth, bitdata, uploadable etc. Every texture loaded with the general texture loading function DEMOGL_TextureLoad (or for cubemaps: DEMOGL_TextureCubeMapLoad) or created using DEMOGL_TextureCreateFromBuffer or DEMOGL_TextureCreateFromFBRegion (or for cubemaps: DEMOGL_TextureCubeMapCreateDynamic) is stored inside the texturestore with a textureobject. With DEMOGL_TextureLoad and DEMOGL_TextureCreateFromBuffer, the actual bitdata, the colorfragments of the texture, are available in main memory and are stored with the textureobject. Textures created with DEMOGL_TextureCreateFromFBRegion have their bitdata stored inside OpenGL and not in main memory.

When a developer wants to use a texture in OpenGL the texture has to be created in OpenGL and the texturedata has to be uploaded. When a texture is created in DemoGL it's not uploaded to OpenGL by default (except the textures created by DEMOGL_TextureCreateFromFBRegion). The developer can do this by calling DEMOGL_TextureUpload. When a texture is no longer needed at a given time, you can remove it from OpenGL (but keep it inside DemoGL's texture store!) by UnUploading the texture using DEMOGL_TextureUnUpload. OpenGL contains some logic that it moves the textures currently uploaded to OpenGL to the videocard's main memory when needed, but in most cases this will not be done that good. Better is to decide which textures should be inside OpenGL at a given time and which textures shouldn't. This can be done easily by calling DEMOGL_TextureUpload and DEMOGL_TextureUnUpload.

The texturestore has more benefits, like sharing textures between effects. When a texture is created inside DemoGL, for example when the texture 'logo.jpg' was loaded using DEMOGL_TextureLoad, and another texture creation call is received for the same texturedata, thus another effect also loads logo.jpg, the caller that wants to load the same texturedata again will receive the same ID as the first caller received and a reference counter inside the textureobject is increased. When the first caller uploads the texture, and another effect does the same, the texture was already uploaded so this relatively slow operation will be avoided and instead an upload reference counter is increased inside the texture object. When then one of the referencing effectobjects UnUploads the texture, it's not really unuploaded, since more effects want it to be uploaded, but just the upload reference counter is decreased. This functionality is build in the texture store, so the developer using the texture functions in the DemoGL API will not notice anything, but just gets the best performance achievable.



Last changed on 02-jun-2001

©1999-2001 Solutions Design