CIS 480 - Advanced Java
Random notes from lecture, 3-26-01

*   Train1.java: example of simple animation in Java;
	*   note how you can create an Image from a .gif file,
	and how to paint an image;

*   why do images flicker when repainted in some applets? because
update(), the applet method called when repaint() is done, clears
the applet(?) and then calls paint();
        *   in AWT, this is done so that paint() doesn't have to
        worry about clearing the applet(?) when repaint() is called ---
        this lets paint() assume a clear screen to start.

        *   but, when repainting images for animation, this clearing
        can cause a somewhat annoying flicker;

*   double-buffering is a technique for avoiding this, smoothing out
such animations;

*   (interesting aside: Swing JApplet is said (in the Java Swing tutorial
at Sun) to override AWT Applet's update() method just to remove this
clearing before calling paint(). I don't know if this means that
double-buffering is less necessary in Swing...)

A SUMMARY OF SOME IMPORTANT POINTS ABOUT DOUBLE-BUFFERING:
(this is for AWT)
 
*   need a "buffer": that'll be a java.awt.Image object

*   need to create this "buffer" using Component.createImage();

*   this buffer needs a Graphics object to draw to: Image.getGraphics()
        can get the Graphics object for this buffer

*   you draw to the buffer's Graphics object, rather than to the Graphics
        object for the applet;

*   when the drawing of the off-screen image is complete, you copy the
        off-screen image onto the applet screen all at once

*   to prevent applet's default update() method from clearing the screen
        before calling paint() as it does whenever repaint() is called, you
        need to override update() so that it just calls paint()

*   see example TrainWiDblBuf.java --- it modifies Train1.java to now
use double-buffering. See the difference?



*   SYNCHRONIZED threads ---

*   threads in Java can be made to communicate with one another;

*   an important concurrent programming idea: you need a "lock"
on something before you can use it;

*   in Java, you have something called synchronize(Object), that allows
you to essentially specify that the thread must have a lock on
Object before it can proceed;

        synchronize(Object)
        {
                // actions safe to do while Object is mine!!

        }
        // other threads can now try to get Object

*   if a number of threads all have a synchronize block on the same
Object, note that actions within that block by any one thread can be 
guaranteed to be being done "all alone" (the other threads are not also 
in their synchronize blocks on that object)...
        *   idea of a "critical region"

* see some examples using this:
        Deadlock.java
        TrySync.java
        TryPhilos.java