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 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.
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.
We find that the only method we need to implement in order to implement an ImageObserver is 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 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.