Efficient loading and rendering of multiple images: Need advice

Question

I have an application that allows the user to customize and display full-screen consoles of various information. The console can have a background image. Additionally, the console can contain any number of components...one of which is a "Image" component.
Both the console background and the image component can refer to multiple images...if multiple images are referenced, the displayed image switches every X seconds.
The application has a repository into which users can load their images so that they are managed by the app.
Now, my problem:
In the old version of my application, I loaded ALL images into memory at startup and when users added them to the repository. This way, each image was available for display very quickly. When it needed to be displayed, I'd just scale it appropriately and display it. Problem is that this used a LOT of memory...I have the full image in memory AND the scaled image in memory.
In the newer version of my application, I now load images from disk on demand. When an image needs to be displayed, it's loaded from disk, scaled and displayed. This uses MUCH less memory...but I'm finding that it's slow and can block my user interface from updating...
I guess I'm probably looking at something in between where I cache the images that MIGHT be displayed by a console. That's better than loading ALL images into memory, and it's better than ALWAYS going to disk. It's just a matter of the logic around finding out what images need to be loaded...loading them in a background thread, blah blah blah.
Anyone had to deal with a problem like this? Any suggestions?
Here's my class that acts as the proxy to the image on disk:
public class ImageProxy extends PersistentComponent {
     public static final long serialVersionUID = 1L;
     public static final String PROP_URL = "URL";
     private URL url;
     public ImageProxy (URL url, String name) throws InstantiationException {
          this.setName(name);
          this.setURL(url);
     public void setURL (URL url) {
          URL oldURL = this.url;
          this.url = url;
          this.changes.firePropertyChange(PROP_URL, oldURL, url);
     public static ImageProxy createImageProxy(File file, XMLParseLog parseLog)
               throws InstantiationException {
          parseLog.inform("Creating new image");
          parseLog.right();
          ImageProxy newImageProxy = null;
          try {
               newImageProxy = new ImageProxy(file.toURL(), file.getName());
               newImageProxy.setSizeOnDisk(file.length());
               newImageProxy.setLastModified(new Date(file.lastModified()));
          } catch (InstantiationException e) {
               parseLog.error(e.getMessage());
               parseLog.left();
               throw e;
          } catch (MalformedURLException e) {
               parseLog.error(e.getMessage());
               parseLog.left();
               throw new InstantiationException(e.getMessage());
          parseLog.left();
          return newImageProxy;
      * Returns the theImage.
      * @return ImageIcon
     public BufferedImage getImage() {
          try {
               return ImageIO.read(this.url);
          } catch (IOException e) {
               return new BufferedImage(100,100,BufferedImage.TYPE_INT_RGB);
     public URL getURL() {
          return url;
}The other option (and it's an easier option) I was thinking of was to have the image proxy class cache the BufferedImage itself upon the first request.
That way, only used images are loaded into memory. I could also then have a thread that would occasionally sweep through all the image proxies and clear out the buffered images of the ones that haven't been requested in X minutes.
Edited by: jneau on May 18, 2008 7:38 PM
Edited by: jneau on May 18, 2008 7:45 PM

Answer 1

I had a similar problem, but with prepared SQL statements--Our solution was similar to your last comment. Without going into the details, we basically made a circular queue that cached the prepared statements, in the system we were using a the time you could only have a set number of prepared statements--and it was not very many, the queue had an aging function so when we had to have a new prepared statement we would use the handle to the one that had the most ancient last referenced time. In this manner we made sure that those statements that were being referenced frequently were the ones that were available.
This does have a few weaknesses:
1 - you still have to stringently manage your limited resources, in your case you're going
to have to tune and do trial and error to find that sweet spot to balance your app.
2 - if you have a bunch of 1 timers, then there is no benefit.