MediaTracker - how to use it, what are the benefits, or is there an alternative?

Question

In the code base, we inherited the use of MediaTracker always performed locally in every block of code.

new MediaTracker(new Canvas()); mediatracker.addImage(i, 1); try { mediatracker.waitForAll(); } catch (InterruptedException e) { } mediatracker.removeImage(i); 

Having decided that this was inefficient, I eventually replaced it with a static instance and method:

 final static protected MediaTracker mediatracker = new MediaTracker(new Canvas()); static protected void checkImageIsReady(Image i) { mediatracker.addImage(i, 1); try { mediatracker.waitForAll(); } catch (InterruptedException e) { } mediatracker.removeImage(i); } 

So far, there have been no negative consequences.

There is another possible approach - to bind MediaTracker to each component (usually to a frame or JFrame), which is strongly implied as the approach that the documentation constructor should use.

I have 2 questions:

• How and why to use MediaTracker?

• Which alternative?

Answer 1

MediaTracker was useful in 1995. Then the main use of the java GUI was Applets, and applets usually downloaded images slowly over the network.

To make it easier to work with Applet authors, java provided us with a nice MediaTracker api that would download images in the background, tracking when they were taken, and even display notifications when the images were partially downloaded . The MediaTracker API meant that applet authors did not need to block the application while the images were loading slowly, and it did not have to write complex stream code to load images in the background stream.

These days you can upload images synchronously, and it is better to use ImageIO . This is especially true for the usual case when images are downloaded from the local file system.

Answer 2

MediaTracker

?

Join us in the 3rd millennium and use ImageIO.read(File/URL/InputStream) . In our millennium, MediaTracker does not matter.