Double-buffering

Also more info here and the newest info on Sun tutorial (but here it is using Swing which automatically does double buffering)

Displaying graphics with standard techniques often result in chunks of the image appearing on screen in spurts. However, graphical applications in Java can allow your program to draw an image in the background, then smoothly display it in total on screen.

This process, known as double-buffering, has two distinct advantages over the ordinary process of drawing directly to the screen:

the user sees one big splat, as the image appears on the screen. While the user views the image, the program can generate the next image and display that image on screen when the user is ready for it - again, all at once
the double-buffering process involves an Image object we can readily pass around to various methods. This capability to manipulate the Image object makes it possible to split our display-building routines into function components, rather than create one huge paint() method to build the screen.

To understand double-buffering, you first need to understand graphics contexts. A graphics context is simply a data structure the system knows how to use as a drawing board. You already have seen and used a graphics context in the paint() method declaration.

public void paint (Graphics g) {

Graphics object g is in our graphics context. We use g to do all the drawing in our applet space:

g.drawString ("HelloWorld!", 25, 25); g.drawRect (12, 12, 45, 8); g.setColor (Color.white);

Java then translates what we draw in g into images on the screen. To perform double-buffering, we need to create a graphics context that is not immediately displayed on the screen.

Creating a graphics context involves two basic steps:

Creating a blank image that has the correct dimensions
Deriving a Graphics object from that image

The Graphics object we build in step 2 serves as our graphics context.

import java.applet.Applet; import java.awt.*; public class Example extends Applet { Dimension offDimension; Image doubleBuffer; Graphics myGC; // could declare MyCanvas c1 //In the update() method, where d holds the size of the //onscreen drawing area: public void update(Graphics g) // Set up our double buffer Dimension d = getSize(); if ( (myGC == null) || (d.width != offDimension.width)|| (d.height != offDimension.height) ) { offDimension = d; doubleBuffer = createImage(d.width, d.height); myGC = doubleBuffer.getGraphics(); // Build a drawing area to work with // could do c1 = new MyCanvas here instead } //First, initialize variables and create the //offscreen buffer as shown above. Then erase the //previous image: myGC.setColor(Color.white); //fills rect with white myGC.fillRect(0, 0, d.width, d.height); myGC.setColor(Color.blue); //Do everything the old paint() method did -- //until we draw the buffered rectangle. // OR use old paint with this graphics area // paint(myGC); ... see below myGC.drawRect(40,40,20,30); //The rest is exactly like the old paint() method //until the very end, when we add the following: //Paint the image onto the screen. g.drawImage(doubleBuffer, 0, 0, this); }

We now use myGC to execute any necessary drawing. Images will be rendered in doublebuffer. When we are ready, we can display our doublebufferto the screen. g.drawImage(doubleBuffer, 0, 0, this);

It's not necessary that the update() method call the paint() method. All that's necessary is that the update() method somehow draw its offscreen buffer to the screen, and that the paint() method be able to draw the proper image when it's called directly by the AWT.

I have seen update call paint and paint call update. Here is paint calling update. Here is the API saying update can call paint

You might wonder why the offscreen image and graphics context are created in the update() method, instead of in (for example) the start() method. The reason is that the image and graphics context depend on the size of the applet Panel's drawing area, and the size of any Component's drawing area is not valid until the Component is just about to be drawn to the screen for the first time.

Once we define the graphics context, we can use it anywhere throughout our program. For example, we could spread our drawing responsibilities across several methods:

public void title() { // Remember our current font Font f = myGC.getFont(); // Pick a fancy font and draw the title myGC.setFont(new Font("TimesRoman",Font.BOLD,36)); myGC.drawString("Spiral example", 15, 50); myGC.drawString("Circles Squared", 15, 80); // Restore our original font myGC.setFont(f); } // return font to original size // draw circles on the edges of a square public void spiral() { int x, y; // Start with the top and bottom of the square y = 100; for (x = 100; x <= 200; x += 10) { myGC.drawOval(x, y, 20, 20); myGC.drawOval(x, y + 100, 20, 20); } // Now do the sides of the square x = 100; for (y = 100; y <= 200; y += 10) { myGC.drawOval(x, y, 20, 20); myGC.drawOval(x + 100, y, 20, 20); } } public void start() { // Do our off-line drawing title(); spiral(); // Now show our image! repaint(); } }

Canvas
Could define a class MyCanvas extends Canvas which has IV's of buffer and graphicContexts which are passed in ...then define a paint method in it like this one

public void paint(Graphics g) { // always receives onscreen graphics as arg // We just need to show the buffered image to the screen g.drawImage(doubleBuffer, 0, 0, this); }

(where doubleBuffer is an image, 0's are ints and this is an imageObserver)

If you tried to use a canvas and double-buffering and got a null pointer exception

Create the buffer in an update() method rather than the init or constructor. See Eliminating Flashing

As said above: You might wonder why the offscreen image and graphics context are created in the update() method, instead of in (for example) the start() method. The reason is that the image and graphics context depend on the size of the applet Panel's drawing area, and the size of any Component's drawing area is not valid until the Component is just about to be drawn to the screen for the first time. and also Working with Graphics

Solving Common Component Problems

Solving Common Painting Problems