Too many images

Greetings all,

I hope this is not too long winded... I have been having a problem with an applet of mine for quite some time now. There are workarounds, but I find them distasteful. I would rather find the root of the problem. The applet is basically a glorified picture viewer which cycles through a series of photos based on user input. My problem is that after 40 pics or so, I get an
OutOfMemory heap error. I'm using the getImage() method to load in the pics.
They're loaded on demand and copied to a (once new'd BufferedImage). Then I use the buffered image for display and control. It all happens in an updatePhoto() method, and goes something like this: (More pseudo code than actual code)

public void updatePhoto(name)
{
Image tmpImage;

tmpImage = getImage(URL, name);

Graphics gTmp = currentImage.createGraphics(); // currentImage is the BufferedImage already created
gTmp.drawImage(tmpImage, 0, 0, this);

}

This all works quite well, until the number of different photos reaches the critical number.

My biggest question is: Does getImage() cache the images onto the heap? This has been my suspicion all along because if I force the applet to handle fewer than the critical number of photos, it will go on forever. If the answer is no, they don't get cached, then I can focus my efforts elsewhere. If the answer is yes, is it possible to remove them from the heap? I can't imagine those who know far more than I would stick me with image data I might need only once.

I am assuming that tmpImage will no longer be valid upon exit since it's a local variable and will be "collected". I have tried forcing garbage collection with no sucess.

Thanks for any help and insight

Try using a JLabel and add an ImageIcon to the label.

That doesn't really answer my question... does getImage() cache images onto the heap?

Quote:

---

I'm using the getImage() method to load in the pics.

---

Quote:

---

Does getImage() cache the images onto the heap?

---

What getImage method?

db

I started out using the Applet.getImage();

tmpImage = getImage(AppletURL, IMAGENAME);

I have also used this:
URL photoSource = myClassName.class.getResource(IMAGENAME);
tmpImage = Toolkit.getDefaultToolkit().createImage(photoSourc e);

and this:
tmpImage = Toolkit.getDefaultToolkit().getImage(getClass().ge tResource(IMAGENAME));

and finally this:
tmpImage = ImageIO.read(getClass().getResourceAsStream(IMAGEN AME));

They all work until the number of different pics reaches critical mass. If the number of pics is lower, I can cycle through all of them over and over forever, which I guess is why I think they're being cached. I use the same BufferedImage for display, so a photo that has been previously loaded is reloaded and recopied to the BufferedImage.

It's possible that Applet#getImage(...) caches the images. I know the similar method of Toolkit does.

There are two possible solutions to your problem:
1. flush() any image you are done with. This releases resources associated with the image.
OR
2. Load your images using ImageIO#read(...). That doesn't cache anything.

Quote:

---

They all work until the number of different pics reaches critical mass.

---

Good observation, and a good approach to troubleshooting.

db

OK, I should probably be flogged for this, but hey...I'm not so arrogant
to think I can't do stupid things, I'm just happy the problem seems to
be fixed.

Anyway, here's what happened... I have other "getImage" calls in this
applet. In an effort to centralize things I created a method to do my
"getImaging". In my updatePhoto() method the sequence went like this:

I used to use:
tmpImage = getImage(AppletURL, IMAGENAME);

which I changed to:
tmpImage = loadMyImage(IMAGENAME);

which called,

Image loadMyImage(String imageName)
{
Image loadImage = null;
try {
loadImage=ImageIO.read(getClass().getResourceAsStr eam(imageName));
} catch (IOException e) {
e.printStackTrace();
}
return loadImage;
}

Then I noticed that after the loadMyImage call, there was
a leftover MediaTracker block to wait for tmpImage to load
completely (because of getImage). When I removed the
MediaTracker block, the problem went away with it.
My theory is that getResourceAsStream() doesn't require
the use of MediaTracker and all these calls to addImage()
and waitForID() were piling up waiting for images that had
long since loaded. Does this make sense?

I'm glad to know that IO.read doesn't cache. Thanks for your help.

"The longer you work on a problem, the more stupid the solution is." - me