Posted by gouessej on Aug 09, 2016; 11:30pm
URL: https://forum.jogamp.org/JOGL-Textures-Hogging-Memory-tp4037027p4037040.html

JimmyNeutron wrote

As for the textures, I'm not sure how the BufferedImage could be part of the problem, since the BufferedImage scope is only the image loading method.

Please use JVisualVM instead of "Activity Monitor" and you'll see more precisely the memory footprint of the Java objects on the Java heap (build-in feature) and on the native heap (requires a plugin).

JOGL creates a buffered image:
https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/util/texture/spi/awt/IIOTextureWriter.java#L67

You see that JOGL creates a buffered image in a particular case:
https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/util/texture/spi/awt/IIOTextureWriter.java#L107

I don't understand what isn't understandable in my previous post. You create a buffered image (~4MB) + JOGL creates a BufferedImage at the beginning of the decoding (~4 MB) + JOGL might create a buffered image in a particular case when decoding the JPEG (~4 MB) + JOGL creates a TextureData object containing the data used to create a texture (~4 MB) and Swing can copy your image in its cache (~4 MB).
If you don't use a buffered image and if you don't use an image format requiring to create a buffered image while decoding, JOGL creates a TextureData object (~4 MB) and that's all.
4 MB < 20 MB What isn't crystal clear in that?
The Swing cache can keep a copy of the buffered image you create beyond its scope. Moreover, the garbage collection takes care of the Java heap, not of the native heap. When a TextureData object is created by (AWT)TextureIO, it creates a direct NIO buffer to store the data used later to create a texture. If you keep a strong reference on this Java object, it won't be garbage collected. If you still have enough available memory on the Java heap, the texture data object won't be garbage collected immediately even though you don't need it and it's the same for the buffered images.

Maybe there is a leak in your source code but anyway, if you use the buffered image only to pass it to AWTTextureIO, why not passing a file or an input stream to TextureIO instead (and preferably not use a JPEG)?

Let me know if something is still unclear.