One thing to note - img.flush() doesn't "dispose" or "free" the image - it only gets rid of cached resources. So the things it gets rid of are:
- For a Toolkit image, it gets rid of the in-memory representation, which can be rebuilt by reloading the image from the source if you use it again. - For a VolatileImage, it gets rid of the VRAM, but you can later get the VRAM back (with uninitialized contents) if you validate it as you might in a rendering loop. - For a BufferedImage, it gets rid of any cached *copies* of the image in VRAM which we create if you copy it to an accelerated destination a few times so that future copies go faster. It does not get rid of the original bits because that is the only source of the image (BI are not typically used in a "validate/restore" loop like a VI, and have no source like a TI). I believe the ImageIcons use TI internally by default so you can flush that image and it will get rid of the in-core version. But, if you use a BI then flush() does nothing (for the Java heap/core memory). BI are only dealt with via Garbage Collection. My guess is that you have an outstanding reference to the image stored somewhere that prevents GC and the flush() simply works around the leaked reference. Can you write a small reproducible test case (like 20 or 30 lines of code) that demonstrates the same leak? If not, then maybe there is a leaked reference lost somewhere in the complexity of your full application...? [Message sent by forum member 'flar' (flar)] http://forums.java.net/jive/thread.jspa?messageID=246654 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
