19

Whenever dealing with the loading and rendering of images in Java, I have previously always used BufferedImages to store and manipulate the images in memory.

However, I have recently come across a few different sites that use the Image class instead of BufferedImage and this got me wondering - what are the differences?

I'm aware that a BufferedImage has a larger/optimised toolset, but does come at any cost? If so, when does this cost become noticeable? In which situations would you use an Image over a BufferedImage, or vice-versa?

Jamie
  • 3,890
  • 3
  • 26
  • 35

2 Answers2

22

BufferedImage extends Image. Image is just a base abstract class and you can't instantiate it. Under the hood you are using BufferedImage or another implementation for sure.

Petar Minchev
  • 46,889
  • 11
  • 103
  • 119
  • 2
    Regarding `"Under the hood you are using BufferedImage for sure"`: not necessarily. There are other concrete implementations of Image that are often used in Java, and one cannot assume that when dealing with a concrete Image instance that it is in fact a BufferedImage. – Hovercraft Full Of Eels Aug 04 '12 at 18:04
  • 1
    Yes true, but in the `JavaDoc` I see the `VolatileImage` as the only another implementation. I edited my answer to be more precise, though. – Petar Minchev Aug 04 '12 at 18:57
  • 1
    Petar: There are others, some that aren't as well documented. I know because I've run into just this situation when obtaining images from Image manipulation filters. All I'm saying is that you cannot make this assumption. 1+ for your edit. – Hovercraft Full Of Eels Aug 04 '12 at 18:58
2

There shouldn't be any real performance difference between directly creating a BufferedImage and a Toolkit image (java.awt.Toolkit or Image#getScaledInstance). You'll never have an actual instance of Image because it's an abstract class; you'll only be dealing with its subclasses (e.g. BufferedImage).

edwga
  • 190
  • 1
  • 8