Memory deallocation using BufferedImage

[chelvis]

I need to deallocate -at the moment- the memory used when I load the PNG files from java.

I use ByteBuffers to store the texture that must be used for openGL, but java maintains the BufferedImage that I used for load the image.

I wrote the following:

image = null;
System.gc();

but I'm surelly that the deallocation never happened.

Othertwise I think that LWJGL stores a copy of the texture loaded for this reason:

when the user changes application <Alt+Tab> the textures stored in video memory doesn't dissappear.

There are any variable or argument that I can change  to avoid this texture duplication?

Thanks: Elvis Enmanuel

[elias]

There isn't. OpenGL automatically stores all textures internally. But that just means that after upload, you can toss the BufferedImage and the ByteBuffer.

- elias

[chelvis]

I think that, but when I use openGL in C++ and I press <Alt+Tab> at the return the textures dissapears (in the same thing that directX) that means that this textures doesn´t use the texture management and I need to store a copy in system memory to upload -when it loss- to the video memory.

how can I 'toss' the ByteBuffer and BufferedImage at the moment in java?

Thanks.

[elias]

Then you are using OpenGL in C++ wrong. OpenGL guarantees that your textures will survice mode switches etc. By tossing I mean to set the reference to null, like you do for the image in your original post.

- elias

[cfmdobbie]

Unless you mean that the textures disappear *from the screen*?

The screenbuffer is maintained by OpenGL, so if you draw an image that includes a texture that you then delete, unless you clear the framebuffer you'll still see the image on-screen.

[chelvis]

I use glDeleteTextures() and glTexImage2D() functions to improve my own texture management, if texture doesn't appears in screen I delete it and when appears an again I upload it from my texture copy in system memory.

In this form openGL -should- have the texture in video memory, because the video memory aren't full.

But don't worry that ain't the problem I test this and works fine in C++.

I only want I know is: how can I release the BufferedImage in java at the moment?

image = null;
System.gc();

this doesn't work, and I have too many memory leaks.

Thanks in advance.

[elias]

It works allright. How can you tell that it doesn't? If you look a the memory taken by the java process you will be wrong - java doesn't shrink it's memory every time a gc runs. You should use Runtime.* methods to get used memory. ByteBuffers won't be counted though.

- elias

[princec]

chelvis,
you should not be deleting textures from OpenGL and keeping them in system memory. That's what OpenGL does for you, automatically. All you're doing is making your program use twice the system memory and slowing it down a whole load.

Cas

[chelvis]

I do exactly this in Java, but  I need to deallocate the memory used when I create a BufferedImage...

[princec]

Ah, no you don't, just forget about it. It'll get freed automatically if you run out of memory.

The other problem with BufferedImage of course is that it's a bit inefficient loading it in and then transferring it to GL via JNI. If you were to load the image directly into a DirectByteBuffer you'd have much better memory usage.

Cas

[oNyx]

>Ah, no you don't, just forget about it. It'll get freed automatically if you run out of memory.

If you use a MediaTracker and dont remove em (from the mediatracker) you will run out of memory (OutOfMemoryException), because the MediaTracker caches em all (it looks like it is doing that forever).

-load an image
-add it to your MediaTracker
-wait for it
-copy it to whatsoever
-remove it from your MediaTracker

However the OutOfMemoryException occours rarly (you need a lot of images to fill up all ram).

[bedelf]

Is there a downside to using javax.imagio.ImageIO.read() instead of mediatracker for applications? I hardly remember any details about this stuff now.

[princec]

You know, in all the years I've used Java I never actually used MediaTracker! Strange but true. I've always used ImageIO.

Cas