Section 7.1
More About Graphics
IN THIS SECTION, we'll look at some additional aspects
of graphics in Java. Most of the section deals with Images, which
are pictures stored in files or in the computer's memory. But we'll also consider
a few other techniques that can be used to draw better or more efficiently.
Images
To a computer, an image is just a set of numbers. The numbers specify
the color of each pixel in the image. The numbers that represent the
image on the computer's screen are stored in a part of memory called a
frame buffer. Many times each second,
the computer's video card reads the data in the frame buffer and
colors each pixel on the screen according to that data. Whenever the
computer needs to make some change to the screen, it writes some new
numbers to the frame buffer, and the change appears on the screen
a fraction of a second later, the next time the screen is redrawn
by the video card.
Since it's just a set of numbers, the data for an image doesn't have
to be stored in a frame buffer. It can be stored elsewhere in the
computer's memory. It can be stored in a file on the computer's
hard disk. Just like any other data file, an image file can be
downloaded over the Internet. Java includes standard classes
and subroutines that can be used to copy image data from one
part of memory to another and to get data from an image file
and use it to display the image on the screen.
The standard class java.awt.Image is used to represent
images. A particular object of type Image contains information
about some particular image. There are actually two kinds of Image
objects. One kind represents an image in an image data file. The
second kind represents an image in the computer's memory. Either type
of image can be displayed on the screen. The second kind of Image
can also be modified while it is in memory. We'll look at this
second kind of Image below.
Every image is coded as a set of numbers, but there are various
ways in which the coding can be done. For images in files, there
are two main coding schemes which are used in Java and on the Internet.
One is used for GIF images, which are usually stored in files that have names
ending in ".gif". The other is used for JPEG images, which
are stored in files that have names ending in ".jpg" or
".jpeg". Both GIF and JPEG images are
compressed. That is, redundancies in the
data are exploited to reduce the number of numbers needed to represent the
data. In general, the compression method used for GIF images works
well for line drawings and other images with large patches of
uniform color. JPEG compression generally works well for photographs.
The Applet class defines a method, getImage, that can be used for
loading images stored in GIF and JPEG files. (As we will see later, stand-alone applications
use a different technique for loading image files.) For example,
suppose that the image of an ace of clubs, shown at the right, is contained
in a file named "ace.gif". And suppose that img is
a variable of type Image. Then the following command could be used
in the source code of your applet:
img = getImage( getCodeBase(), "ace.gif" );
This would create an Image object to represent the ace. The second parameter is
the name of the file that contains the image. The first parameter specifies the
directory that contains the image file. The value "getCodeBase()"
specifies that the image file is in the code base directory for the applet.
Assuming that the applet is in the default package, as usual, that just means
that the image file is in the same directory as the compiled class file
of the applet.
Once you have an object of type Image, however you obtain it,
you can draw the image in any graphics context. Most commonly, this will be
done in the paintComponent() method of a JPanel (or some
other JComponent.) If g is the Graphics object
that is provided as a parameter to the paintComponent() method, then the
command:
g.drawImage(img, x, y, this);
will draw the image img in a rectangular area in the component. The parameters x
and y give the position of the upper-left corner of the rectangle in which
the image is displayed, and the rectangle is just large enough to hold the image.
The fourth parameter, this, is the special variable from Section 5.5
that refers to the component itself. This parameter is there for technical reasons
having to do with the funny way Java treats image files. (Although you don't
really need to know this, here is how it works: When you use getImage() to create an
Image object from an image file, the file is not downloaded immediately. The
Image object simply remembers where the file is. The file will be downloaded the
first time you draw the image. However, when the image needs to be downloaded,
the drawImage() method only initiates the downloading. It doesn't wait for
the data to arrive. So, after drawImage() has finished executing, it's quite
possible that the image has not actually been drawn! But then, when does it get drawn?
That's where the fourth parameter to the drawImage() command comes in.
The fourth parameter is something called an ImageObserver. After the
image has been downloaded, the system will inform the ImageObserver that
the image is available, and the ImageObserver will actually draw the
image at that time. For large images, it's even possible that the image will
be drawn in several parts as it is downloaded. Any JComponent object
can act as an ImageObserver. If you are sure that the image that you
are drawing has already been downloaded, you can set the fourth parameter of
drawImage() to null.)
There are a few useful variations of the drawImage() command.
For example, it is possible to scale the image as it is drawn to a specified
width and height. This is done with the command
g.drawImage(img, x, y, width, height, this);
The parameters width and height give the size of the
rectangle in which the image is displayed.
Another version makes it possible to draw just part of the image. In the
command:
g.drawImage(img, dest_x1, dest_y1, dest_x2, dest_y2,
source_x1, source_y1, source_x2, source_y2, this);
the integers source_x1, source_y1, source_x2, and source_y2
specify the top-left and bottom-right corners of a rectangular region in the source image.
The integers dest_x1, dest_y1, dest_x2, and dest_y2
specify the corners of a region in the destination graphics context. The specified
rectangle in the image is drawn, with scaling if necessary, to the specified rectangle
in the graphics context. For an example in which this is useful, consider a card
game that needs to display 52 different cards. Dealing with 52 image files can be
cumbersome and inefficient, especially for downloading over the Internet. So, all
the cards might be put into a single image:
Now, only one Image object is needed. Drawing one card means drawing
a rectangular region from the image. This technique is used in the following
version of the HighLow card game
from Section 6.6:
In this applet, the cards are drawn by the following method. The variable,
cardImages, is a variable of type Image that represents the image
of 52 cards that is shown above. Each card is 40 by 60 pixels. These numbers are
used, together with the suit and value of the card, to compute the corners of
the source and destination rectangles for the drawImage() command:
void drawCard(Graphics g, Card card, int x, int y) {
// Draws a card as a 40 by 60 rectangle with
// upper left corner at (x,y). The card is drawn
// in the graphics context g. If card is null, then
// a face-down card is drawn. The cards are taken
// from an Image object that loads the image from
// the file smallcards.gif.
if (card == null) {
// Draw a face-down card
g.setColor(Color.blue);
g.fillRect(x,y,40,60);
g.setColor(Color.white);
g.drawRect(x+3,y+3,33,53);
g.drawRect(x+4,y+4,31,51);
}
else {
int row = 0; // Which of the four rows contains this card?
switch (card.getSuit()) {
case Card.CLUBS: row = 0; break;
case Card.HEARTS: row = 1; break;
case Card.SPADES: row = 2; break;
case Card.DIAMONDS: row = 3; break;
}
int sx, sy; // Coords of upper left corner in the source image.
sx = 40*(card.getValue() - 1);
sy = 60*row;
g.drawImage(cardImages, x, y, x+40, y+60,
sx, sy, sx+40, sy+60, this);
}
} // end drawCard()
The variable cardImages is defined as an instance variable in the
applet, and the image object is created in the init() method of the
applet with the command:
cardImages = getImage( getCodeBase(), "smallcards.gif" );
The complete source code for this applet can be found in HighLowGUI2.java.
Off-screen Images and Double Buffering
In addition to images in image files, objects of type Image can be used
to represent images stored in the computer's memory. What makes such images particularly
useful is that it is possible to draw to an Image in the computer's memory.
This drawing is not visible to the user. Later, however, the image can be copied very
quickly to the screen. In fact, this technique is used automatically in Swing to
draw the components that you see on the screen. When the on-screen picture needs
to be redrawn, the new picture is drawn step-by-step to an off-screen image.
This can take some time. If all this drawing were done on screen,
the user would see the image flicker as it is drawn. Instead, a complete new image replaces the old
one on the screen almost instantaneously. The user doesn't see all the steps involved in
redrawing. This technique makes smooth, flicker-free animation and dragging easy in
Swing. (It is not at all easy or automatic when using the older AWT GUI components. This
is one big advantage of Swing.)
The technique of drawing an off-screen image and then quickly copying the image to the screen is
called double buffering. The name comes from the term
"frame buffer," which refers to the region in memory that holds the image on the screen.
(In fact, true double buffering uses two frame buffers. The video card can display either
frame buffer on the screen and can switch instantaneously from one frame buffer to the other.
One frame buffer is used to draw a new image for the screen.
Then the video card is told to switch from one frame buffer to the other. No copying
of memory is involved. Double-buffering as it is implemented in Java does require copying,
which takes some time and is not perfectly flicker-free.)
It's possible to turn off double buffering in Swing (although there is little reason to do so).
To help you understand the effect of double buffering,
here are two applets that are identical, except that one uses double buffering and
one does not. You can drag the red squares around the applets. I've added
a lot of lines in the background to increase the time it takes to redraw the
applet. You should notice an annoying flicker in the non-double-buffered
applet on the left:
Swing's double buffering uses an off-screen image. Sometimes, it's useful to
create your own off-screen images for other purposes.
An off-screen Image object
can be created by calling the instance method createImage().
This method is defined in the Component class, and so can be used just
about anywhere in an applet's source code.
The createImage() method takes two parameters to specify the
width and height of the image to be created. For example,
Image offScreenImage = createImage(width, height);
Drawing to an off-screen image is done in the same way as any other drawing in Java,
by using a graphics context. The Image class defines an instance method
getGraphics() that returns a Graphics object that can be used for
drawing on the off-screen image. (This works only for off-screen images.
If you try to do this with an Image from
a file, an error will occur.) That is, if offScreenImage is a variable
of type Image that refers to an off-screen image, you can say
Graphics offscreenGraphics = offScreenImage.getGraphics();
Then, any drawing operations performed with the graphics context offscreenGraphics
are applied to the off-screen image. For example, "offscreenGraphics.drawRect(10,10,50,100);"
will draw a 50-by-100-pixel rectangle on the off-screen image. Once a picture has been
drawn on the off-screen image,
the picture can be copied into another graphics context,
using the graphics context's drawImage() method. For example:
g.drawImage(offScreenImage,0,0,null). For an off-screen image, the file parameter
to drawImage() can be null. (Since the image is already in memory, there
is no need for an "ImageObserver" to wait for the image to be loaded from a file.)
Off-screen images can be used to solve one problem that we have seen in many of
our sample applets. In many cases, we have had no convenient way of remembering
what was drawn on an applet, so that we were unable restore the drawing when necessary.
For example, in the paint applet in
Section 6.6, the user's sketch will disappear if the applet
is covered up and then uncovered. An off-screen image can be used to solve this
problem. The idea is simple: Keep a copy of the drawing in an off-screen image.
When the component needs to be redrawn, copy the off-screen image onto the screen.
This method is used in the improved paint program at the end of this section.
When used in this way, the off-screen image should always contain a copy of the
picture on the screen. The paintComponent() method
copies this off-screen image to the screen. This will refresh the picture
when it is covered and uncovered. The actual drawing of the picture should take
place elsewhere. (Occasionally, it makes sense to draw some extra stuff on
the screen, on top of the image from the off-screen image. For example,
a hilite or a shape that is being dragged might be treated in this way. These
things are not permanently part of the image. The permanent image is
safe in the off-screen image, and it can be used to restore the on-screen
image when the hilite is removed or the shape is dragged to a different location.
We will use this technique in the next example.)
There are two approaches to keeping the image on the screen synchronized with the
image in the off-screen image. In the first approach, in order to change the
image, you make the change to the off-screen image and then call repaint()
to copy the modified image to the screen. This is safe and easy, but not always efficient.
The second approach is to make every change twice, once to the off-screen image and
once to the screen. This keeps the two images the same, but it requires some care to
make sure that exactly the same drawing is done in both (and it violates the
rule about doing drawing operations only inside paintComponent() methods).
When using an off-screen image as a backup for the picture displayed on a component,
the size of the off-screen image should be the same as the size of the component.
This raises the problem of where in the program the image should be created. If the
off-screen image is to fill an entire applet, then the image can be created in the
applet's init() method with the command:
offScreenImage = createImage(getSize().width,getSize().height);
However, components other than applets do not have convenient init() methods
for initialization. They have constructors, but the size of a component is not known
when its constructor is executed, so the above command will not work in a constructor.
An alternative is to create the off-screen image on demand, when it is needed.
We can even allow for changes in size of a component if we make a new off-screen
image whenever the size changes. Here is some sample code that implements this idea.
A method named checkOffScreenImage() will create the off-screen image when
necessary. This method should always be called before using the off-screen image.
For example, it is called in the paintComponent() method before copying
the image to the screen.
/* Some variables used for double-buffering. */
Image OSI; // The off-screen image (created in paintComponent()).
int widthOfOSI, heightOfOSI; // Current width and height of OSI.
// These are checked against the size
// of the component, to detect any change
// in the component's size. If the size
// has changed, a new OSI is created.
// The picture in the off-screen image
// is lost when that happens.
void checkOffScreenImage() {
// This method will create the off-screen image if it has not
// already been created or if the component's size has changed.
// It should always be called before using the off-screen
// image in any way.
if (OSI == null || widthOfOSI != getSize().width
|| heightOfOSI != getSize().height) {
// OSI doesn't yet exist, or else it exists but has a
// different size from the component's current size.
// Create a new OSI, and fill it with the component's
// background color.
OSI = null; // If OSI already exists, this frees up the memory.
widthOfOSI = getSize().width;
heightOfOSI = getSize().height;
OSI = createImage(widthOfOSI, heightOfOSI);
Graphics OSGr = OSC.getGraphics();
OSGr.setColor(getBackground());
OSGr.fillRect(0, 0, widthOfOSC, heightOfOSC);
OSGr.dispose(); // Free operating system resources.
}
}
public void paintComponent(Graphics g) {
// Paint the component by copying the off-screen image onto
// the screen. First, call checkOffScreenImage() to make
// sure that the off-screen image is ready.
// (Note that since the image fills the entire component,
// it is not necessary to call super.paintComponent(g).)
checkOffScreenImage();
g.drawImage(OSI, 0, 0, null); // Copy OSI onto the screen.
// Note: At this point, we could draw hiliting or other extra
// stuff on top of the picture in the off-screen image.
}
Note that the contents of the off-screen image are lost if the size changes.
If this is a problem, you can consider copying the contents of the old off-screen
image to the new one before discarding the old image. You can do this with
drawImage(), and you can even scale the image to fit the new size if
you want. However, the results of scaling are not always attractive.
Here is an applet that demonstrates some of these ideas. Draw red lines
by clicking and dragging on the applet. Draw blue rectangles by
right-clicking and dragging. Hold down the shift key and click to clear
the applet. Notice that as you drag the mouse, the figure that you are
drawing stretches between the current mouse position and the point where
you started dragging. This effect is sometimes called a rubber
band cursor:
In this applet, a copy of the picture that you've drawn is kept in an
off-screen image. If you cover the applet and uncover it, the picture
is restored by copying this backup image onto the screen. When you drag
the mouse, the figure that you are drawing is not added to the off-screen
image. The paintComponent() method simply draws the new figure
on top of the backup image. The backup image is not changed, and as you
move the mouse around, you can see that it is still there, "underneath" the
figure you are sketching. The new figure is only added to the off-screen
image when you release the mouse button. To see how all this works in
detail, check the source code, RubberBand.java.
There is one other point of interest in the above applet. To draw a rectangle in Java,
you need to know the coordinates of the upper left corner, the width, and
the height. However, when a rectangle is drawn in this applet, the available data consists of two
corners of the rectangle: the starting position of the mouse and its current position.
From these two corners, the left edge, the top edge, the width, and the
height of the rectangle have to be computed. This can be
done as follows:
void drawRectUsingCorners(Graphics g, int x1, int y1, int x2, int y2) {
// Draw a rectangle with corners at (x1,y1) and (x2,y2).
int x,y; // Coordinates of the top-left corner.
int w,h; // Width and height of rectangle.
if (x1 < x2) { // x1 is the left edge
x = x1;
w = x2 - x1;
}
else { // x2 is the left edge
x = x2;
w = x1 - x2;
}
if (y1 < y2) { // y1 is the top edge
y = y1;
h = y2 - y1;
}
else { // y2 is the top edge
y = y2;
h = y1 - y2;
}
g.drawRect(x, y, w, h); // Draw the rect.
}
Rectangles, Clipping, and Repainting
The example we've just looked at has one glaring inefficiency:
Every time the user drags the mouse, the entire applet is repainted,
even though only a small part of the picture might need to be changed.
It's possible to improve on this by repainting only a part of the
applet. There is a second version of the repaint()
command that makes this possible. If comp is a variable
that refers to some component, then
comp.repaint( x, y, width, height );
tells the system that a rectangular area in the component needs
to be repainted. The first two parameters, x and y,
specify the upper left corner of the rectangle and the next two
parameters give the width and height of the rectangle.
In response to this, the system will call paintComponent()
as usual, but the graphics context will be set up for drawing
only in the specified region. This is done by setting the
clip region of the graphics context.
The clip region of a graphics context specifies the area
where drawing can occur. Any attempt to use the graphics
context to draw outside the clip region is ignored. (If part of
a shape lies outside the clip region, that part is "clipped off"
before the shape is drawn on the screen.) Only the pixels inside
the clip region need to have their color set, and this can be
much more efficient than setting the color of every pixel in
the component. When an off-screen image is copied onto the
component, only the part that lies within the clip region is
actually copied.
The techniques covered in this section can be used to improve the
simple painting program from Section 6.6.
The new version uses an off-screen image to save a copy of the
user's work, and it uses the version of repaint() discussed
above. As before, the user can draw a free-hand sketch. However,
in this version, the user can also choose to draw several shapes by selecting
from the pop-up menu in the upper right. Try it out! Check that when you cover up
the applet with another window, your drawing is still there when you uncover it.
The source code for this improved paint applet is in the file SimplePaint3.java.
It uses an off-screen image pretty much in the way described above. The paintComponent()
method copies the off-screen image to the screen, and as the user drags the mouse,
clipping is used to restrict the drawing to the region that actually needs to be changed.
In this applet, curves are handled differently from the other shapes.
Suppose that the user is sketching a curve and that the user moves the
mouse from the point (prevX,prevY) to the point (mouseX,mouseY).
The applet responds to this by drawing a line segment in the off-screen image
from (prevX,prevY) to (mouseX,mouseY). To make this change
appear on the screen, a rectangle that contains these two points must be
copied from the off-screen image onto the screen. This is accomplished in
the applet by calling repaint(x,y,w,h) with appropriate values for
the parameters.
When the user is sketching one of the other shapes in the applet, the
rubber band cursor technique is used. That is, while the user is dragging
the mouse, the shape is drawn by the paintComponent() method
on top of the picture from the off-screen image. Let's say, for example, that the user
is drawing a rectangle. Suppose that the user starts by pressing the mouse
at the point (startX,startY). Consider what happens later, when the
user drags the mouse from the point (prevX,prevY) to the point
(mouseX,mouseY). At the beginning of this motion, a rectangle
is shown on the screen with corners at (startX,startY) and
(prevX,prevY). In response to the motion, this rectangle must be
removed and a new one with corners at (startX,startY) and
(mouseX,mouseY) should appear.
This can be accomplished by changing the values of the variables that
tell paintComponent() where to draw the rectangle and by
calling repaint(x,y,w,h) twice: once to repaint the area occupied
by the old rectangle and once to repaint the area that will be occupied
by the new rectangle. (The system will actually combine the two operations
into a single call to paintComponent().)
This version of "SimplePaint" is not really all that simple. There are a lot
of details to take care of. I urge you to look at the source code
to see how it's done.
FontMetrics
In the rest of this section, we turn from Images to look briefly at
another aspect of Java graphics.
Often, when drawing a string, it's important to know how big the image of the
string will be. You need this information if you want to center a string on
an applet. Or if you want to know how much space to leave between two lines
of text, when you draw them one above the other. Or if the user is typing the
string and you want to position a cursor at the end of the string. In Java, questions
about the size of a string are answered by an object belonging to the
standard class java.awt.FontMetrics.
There are several lengths associated with any given font. Some of them
are shown in this illustration:
The red lines in the
illustration are the baselines
of the two lines of text. The suggested distance between two
baselines, for single-spaced text, is known as the lineheight
of the font. The ascent is the distance that tall characters
can rise above the baselines, and the descent is the distance
that tails like the one on the letter g can descend below the baseline. The ascent and
descent do not add up to the lineheight, because there should be some extra space between
the tops of characters in one line and the tails of characters on the line above.
The extra space is called leading. All these quantities
can be determined by calling instance methods in a FontMetrics object.
There are also methods for determining the width of a character and the width of
a string.
If F is a font and g is a graphics context, you can get a
FontMetrics object for the font F by calling g.getFontMetrics(F).
If fm is a variable that refers to the FontMetrics object, then
the ascent, descent, leading, and lineheight of the font can be obtained by calling
fm.getAscent(), fm.getDescent(), fm.getLeading(), and fm.getHeight().
If ch is a character, then fm.charWidth(ch) is the width of the character
when it is drawn in that font. If str is a string, then fm.stringWidth(str)
is the width of the string. For example, here is a paintComponent() method that shows the message
"Hello World" in the exact center of the component:
public void paintComponent(Graphics g) {
int width, height; // Width and height of the string.
int x, y; // Starting point of baseline of string.
Font F = g.getFont(); // What font will g draw in?
FontMetrics fm = g.getFontMetrics(F);
width = fm.stringWidth("Hello World");
height = fm.getAscent(); // Note: There are no tails on
// any of the chars in the string!
x = getSize().width / 2 - width / 2; // Go to center and back up
// half the width of the
// string.
y = getSize().height / 2 + height / 2; // Go to center, then move
// down half the height of
// the string.
g.drawString("Hello World", x, y);
}
