Over the years, a few people have come across and used a bit of code I wrote for Imagine. You basically have the problem that Java image data is stored on the heap as giant byte arrays and you quickly run out of memory.
Over the years, a few people have come across and used a bit of code I wrote for Imagine . You basically have the problem that Java image data is stored on the heap as giant byte arrays and you quickly run out of memory.One of the JDK team guys assured me about two years ago that with JDK 7 this would no longer be a problem - but I got no sense that he either understood what the problem was, and I couldn't think of a way you could really solve it without doing your own memory management. Say you're writing an image editor application. "Tools" draw on the surface of an image. You want to provide undo support. You have a few options:
Strategy 2 definitely makes more sense. But what to do with the old image data you might never reuse? You could use ImageIO and write it out in some format, but that turns out to be deathly slow.The solution was ByteNIOBufferedImage  - it's a regular BufferedImage you can treat like any other. But its backing data is a index into a memory-mapped file (there are still fragmetation issues to be solved - this *is* doing home-grown memory management, the thing Java is supposed to save us from). You don't want to take one of these images and paint it straight to the screen - it will be non-accellerated and pretty much deathly slow. But it does provide a way to store semi-unlimited amounts of image data for a Java app without requiring huge heap sizes. Anyway, it's definitely not for everyone but I've gotten enough private emails from people who wanted to use it that it seemed worth mentioning.