Images and Animation


Lets begin with the UM - St. Louis Virtual Tour.

Now a very simple example of an applet that loads an image into the applet panel. The example takes the two required steps.

The form of getImage that appears here is
Image getImage(URL , String)

In effect, the String is appended to the URL to form the URL of the "gif" of the image we wish to load. The Java consol window helps clarify this point. In this case the image can be found in the same directory as the applet code.

The role of g. drawImage(imgs,1, 1,this); is reasonably clear, the image is placed in the applet panel with upper left at 1,1(1 in and 1 down). Less obvious, perhaps, is the mechanism that causes paint() to be called. In fact, it is called as part of the screen painting sequence that is initiated after start() completes.

The role of this as a parameter of getImage() is interesting! In the API documentation we see that the parameter position occupied by this is an ImageObserver. Image Observer is, an Interface. . A good way of thinking about an Image Observer is as a "hook" to the image loading and drawing process with respect to the particular browser that the applet is running under. This issue will be discussed in some detail below.

To begin the discussion, remember that the image in the preceding example loaded slowly rather than "flashing" on the screen. The reason for this is that getImage() returns immediately almost certainly, before the image is loaded. Thus drawImage() does not have a full image to paint.
Obviously, somehow, drawImage() is called repeatedly as the image is loading. Here the Image Observer plays a critical role.

The next example demonstrates API support for Synchronizing Image Loading using a MediaTracker.
The role of a MediaTracker is to block the applet till the image is fully loaded.

Finally, before beginning the detailed discussion promised above, one final example which provides information about putting images in Components and some clues about animation.

We now introduce three methods that provide much of the machinery that is in the background in the above examples.


and
The importance of imageUpdate() can be seen by looking in the API documentation.

We find that the only method we need to implement in order to implement an ImageObserver is imageUpdate().

Moreover,
public abstract class Component implements ImageObserver
Thus every component which can be instantiated must have an implementation of imageUpdate()!

This method provides a powerful "hook" to the graphics of the underlying operating system by passing status information about images to user defined classes that implement it.

For example,
f & ImageObserver.ALLBITS !=0
tells us that the image is now complete.

For the moment, it suffices to note that the default implementation of update() is called to prepare a component's "screen area" for paint() which it calls. Here is an example. The Java Console provides a view of the various call sequences.

While, it is frequently the case that calls to update() and paint() are caused by system Events it is possible for an application to "schedule" a screen refresh with redraw() the next example provides such a use. Again, the Java Console provides a view of the various call sequences. The point to observe is that but_next causes repaint() to be called. This, in turn, calls update() which, in turn, calls paint(). This sequence is necessary to "refresh" the entire Canvas. but_last just calls paint(), which only "draws" the next image part of the screen.

Note: it is only the nCanvas part of the screen that we want to redraw() so we need to send super.update() the proper Graphics.


URL: https://www.umsl.edu/~siegelj/newcourse/part4/iman.htm
Copyright: Jerrold Siegel for The University of Missouri -St. Louis
Last modified on 10/29/2000 14:46:30