Textures in RAM & VRAM?

OpenGL Development JOGL Development
#1

Hi!

I have a strange expirience with the textures in my game, i’m using the TextureIO class to generate the textures from my images, first i’m creating a TextureData object which gets a buffered image with the image data, after that i create the texture using TextureIO.newTexture() with the TextureData object, everything is working nicely except that somehow the texture is hold in RAM & in VRAM when i call texture.dispose the texture gets removed from RAM & VRAM. I don’t know if it should work like this but i thought once i call TextureIO.newTexture the texture gets uploaded from RAM to the VRAM and thus isn’t resident in RAM anymore.

I also thought that the texture might hold a reference to the TextureData object which isn’t removed properly, but there isn’t a good documentation on how to use the Fluser interface provided by jogl so i havn’t tryed it yet.

here’s some code snipped how i’m doing the texture generation:


TextureData textureData = TextureIO.newTextureData( bufferedImage , true );
textureData.getBuffer(  ).rewind(  );
Texture texture = TextureIO.newTexture( textureData);
textureData.setBuffer(null);

i hope that someone can help me solve this problem, and if it’s not solvable i would like to know why the textures are hold in RAM & VRAM.

thanks in advance
greetings from vienna (austria)

#2

I think this is just the normal way that image data (textures) are handled by computer systems.
You first make a texture and it takes-up space in RAM, and then when the application needs it, it creates a copy of it in VRAM, the video card does whatever it needs with it. The texture will then stay in VRAM depending upon it’s settings/requirements/lifetime, so it may be deleted from VRAM and copied back several times during the life of your app (there are ways to make it stay in VRAM though). It’ll also stay in regular system memory until you choose to delete it.

#3

The Texture object doesn’t hold a reference to the TextureData, so you shouldn’t see any heap consumption from it. You may want to call TextureData.flush() after creating your Texture object, though I think this is a no-op except for reading certain kinds of textures from files on disk using memory mapping. Once you’ve released all references to your TextureData you should eventually see the Java heap consumption associated with it go away.