I've just checked the source for BufferedImage, and flush() seems
to be an
empty method - not even a call to super.flush(). That seems rather
odd to
me.
The superclass of BufferedImage is java.awt.Image, which has an
abstract
flush(). No purpose would be served by calling super.flush(). I'm
not
even sure it would compile. Doing so would specifically ask to
invoke an
abstract non-virtual method, which seems slightly illegal to me,
but may
nonetheless be allowed; try it and see.
The 1.4 source I have does show a body for BufferedImage.flush():
public void flush() {
// MACOSX
if (this.sData != null)
{
sData.finishLazyDrawing();
}
}
Apparently, the implementation of BufferedImage.flush() may vary.
There is more to BufferedImage than meets the eye and I'm not sure
that looking at the source will help that much. Where possible,
BufferedImages are mirrored in VRAM and the two copies have to be
kept synchronized: if you use Graphics to draw, then the mirrored
version is drawn into whereas if you access the pixels directly, the
'real' version is drawn into. You can get into a pickle sometimes
when you mix the two and confuse the JVM. This all requires a lot of
housekeeping and it must be stored somewhere, either in the
BufferedImage itself or in a table somewhere. It's possible that the
leaks are due to some of this housekeeping not being cleared up.
Also, it wouldn't surprise me a bit if a lot of the code in
BufferedImage is never called and the BufferedImage class recognised
as a special case by the runtime. Consider AlphaComposite: it's full
of code that never gets called because the runtime spots that you're
using AlphaComposite and calls its own optimized C code instead.
Looking at the code may help, or it may not :-)
Jerry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
