JOGL texture objects and java.nio buffer reclaiming

OpenGL Development JOGL Development
#1

I’m migrating my code to use the JSR-231 release, and would really like to use the new Texture classes. Only I have considerable worries about the re-use of java.nio buffers. From what I’ve read JVMs (or some JVMs) are not good at freeing memory allocated in unused buffers.

So is it feasible to use the new Texture classes if one’s application is continually loading large textures? Or after loading 100 such textures will one’s Java process just hit out of memory conditions?

#2

It depends on the file format of the textures you’re loading. By and large the TextureIO classes only use heap-allocated buffers for storage, not direct buffers. The DDS image reader uses memory-mapped files which can be problematic if you open lots of them and they aren’t reclaimed eagerly enough by the GC. All of the file formats handled by ImageIO including JPEG and PNG use heap-allocated storage (BufferedImages, actually) before the textures are converted to OpenGL format.

#3

Thanks for the reply! Does a direct buffer get used when the texture is transferred from CPU memory to the graphics card? If so is there an issue there?

#4

No, a direct buffer is not used, since glTexImage2D / glTexSubImage2D are synchronous and don’t reference the incoming memory afterward.

#5

i had a related question …
i am using textures for displaying images . As the full resolution image is very large i cant load the texture for the full resolution image at once . so i load a scaled down low res. image ( i pick up the image from Oracle Spatial database) and when the user zooms to a particular area i replace the zoomed area with a better resolution image using subTextures .

      my question is can i free the memory for the subtexture when the subtexture area goes out of view (like due to pan by user to a different area) . so that some other subtexture can be loaded with out eventually running out of memory .

thanks

schiz

#6

You can destroy textures, which suffer no memoryleak.

Yet, I would advice you to reuse a pool of buffers, as reusing is much faster than recreating. You reuse a texture by supplying a new sub-texture for the whole dimensions of the texture.