Capture Image Of A Very Large JPanel

Question

Below is some code used to save an image of a JPanel to a file...
    int w = panel.getSize().width;
    int h = panel.getSize().height;
    BufferedImage image = new BufferedImage(w, h, BufferedImage.TYPE_INT_RGB);
    Graphics graphics = image.getGraphics();
    // Make the component believe its visible and do its layout.
    panel.addNotify();
    panel.setVisible(true);
    panel.validate();
    // Draw the graphics.
    panel.print(graphics);
    // Write the image to a file.
    ImageFile imageFile = new ImageFile("test.png");
    imageFile.save(image);
    // Dispose of the graphics.
    graphics.dispose();This works fine but my problem is that I am trying to save what may be a very large JPanel, perhaps as large as 10000x10000 pixels. It doesn't take long for the java heap to be used up and an exception to be thrown.
I know I can increase the heap size of the JVM but since I can't ever be sure how large the panel may be that's a far from ideal solution.
So the question is how do I save an image of a very large JPanel to a file?

Answer 1

1) Does the OoM happens while instantiating the buffered image, (which probably tries to allocate a big continuous native array of pixels)?
Or the Graphics object (same reason, though the Graphics is probably just an empty shell over the big pixel array)?
2) In which format do you need to save the image? Do you only need to be able to read it again in your own program?
If yes to both questions, then a pulled-by-the-hair solution coud be to instantiate your own Graphics subclass (no Buffered Image), whose operations would save their arguments directly to the image file, instead of into a big in-memory model of the panel image.
If the output format is a standard one though (GIF, JPG,...), then maybe your custom Graphics's operations could contain the logic to encode/compress as much as possible of the arguments into an in-memory bytearray of the target format?
I'm not very confident though; I d'ont know the GIF or JPEG encoding, but I suspect (especially for JPEG) that you need to know the "whole" image to encode it properly.
But if the target format supports encoders that work on the fly out of streams of bytes (e.g. BMP ) then you can use whatever compress/uncompress technique you see fit (e.g. RLE ): you know the nature of the panels, you may be aware of some optimizations you may perform wrt pixels storage. prior to encoding (e.g., bug empty areas, predictable chessboard pattern, black-and-white palette,...).
Edited by: jduprez on Sep 19, 2009 7:33 PM