Michael Ellis wrote:
>Apparently, the library documentation has not been updated, because when I
>check the type of the returned objects in the debugger, I find that I am
>receiving "apple.awt.OSXImage" instances, not the BufferedImage instances I
>expected.
That is truly remarkable! I was going to suggest that apple.awt.OSXImage
might subclass BufferedImage, but when I check the 1.4.2 jars, neither
apple.awt.OSXImage nor its superclass sun.awt.image.Image subclasses
BufferedImage. Yet somehow, this isn't considered a type-safety error.
I wonder what would happen if the code called a BufferedImage method that
isn't there, such as any of the tile methods, any property methods, or even
just isAlphaPremultiplied().
The superclass sun.awt.image.Image does have a getBufferedImage() method,
so these seem to be representable as BufferedImages, without being one
themselves.
>So, perhaps we have an explanation here. I've found that flush()ing my
>images made a big difference in my program's ability to reclaim memory,
>but, as we thought we were using BufferedImages, we were unable to
>determine why this action would matter for that particular java.awt.Image
>variant. In fact, it would seem that this library method I am using is not
>returning the promised BufferedImage, but instead a different Image
>subclass. Hence, the flush() method is useful for the actual instance
>returned.
Since flush() is documented as releasing caching information, it's possible
for a BufferedImage subclass to implement flush() to discard everything
volatile, keeping only the pixel-data and minimal pixel-model info. The
gain from flush() has nothing to do with whether the object is a
BufferedImage or not.
If the object itself is GC'ed correctly, the flush() would be irrelevant.
Because it's not being GC'ed correctly, the flush() is making up for most
of what the GC isn't accomplishing. The not-a-BufferedImage bug/feature is
orthogonal to the isn't-cleaning-up-correctly bug.
>I suppose the lesson learned here is that if you only know you're going to
>acquire some generic java.awt.Image subclass, go ahead and make
>arrangements to flush() it.
I think the other lesson is that there's a bug in apple.awt.OSXImage and/or
in sun.awt.image.Image, and calling flush() is a work-around to make it
release most of the memory resources it's holding.
-- GG
_______________________________________________
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
This email sent to email@hidden
