If you were to use everything you’ve learned thus far
to build an animated MIDlet using the regular MIDP Canvas class, you
would find that the resulting animation has an annoying flicker. This
flicker occurs because the game screen is cleared before the animated
graphics are painted. In other words, animated graphics objects are
erased and repainted each time they are moved. Because the erase and
repaint process takes place directly on the game screen, the animation
appears to flicker. To better understand the problem, imagine a movie in
which a blank background is displayed quickly in between each frame
containing actors that move. Although the film is cooking along at a
fast enough pace to give the illusion of movement, you would still see a
noticeable flicker because of the blank backgrounds.
You can solve the flicker problem associated with sprite animation by using a technique known as double buffering.
In double buffering, you perform all your erasing and drawing on an
offscreen drawing surface that isn’t visible to the user. After all the
drawing is finished, the end result is painted straight to the game
screen in one pass. Because no visible erasing is taking place, the end
result is flicker-free animation. Figure 5.6 shows the difference between traditional single-buffer animation and double-buffer animation that eliminates flicker.
Figure 1. Double-buffer animation eliminates the annoying flicker associated
with drawing directly to the game screen with a single buffer.
is simply an area in memory to which you are drawing graphics. The
buffer in traditional single-buffer animation is the game screen itself,
whereas double-buffer animation adds an offscreen memory buffer to the
reveals how an offscreen memory buffer is used to perform all the
incremental animation drawing, with only the finished image being drawn
to the game screen. This might sound like a tricky programming problem,
but double-buffering is extremely easy to incorporate into your mobile
games thanks to the MIDP 2.0 API.
In addition to the standard Canvas class, the MIDP API offers the GameCanvas class, which supports double-buffered graphics. To take advantage of this feature in the GameCanvas class, you simply derive your game-specific canvas from the GameCanvas
class and paint the graphics just as you would in a normal MIDlet.
However, all the painting you perform is actually being done to an
offscreen buffer. To commit the offscreen painting to the actual screen,
you must call the flushGraphics() method.
To recap how the offscreen buffer works in the GameCanvas
class, a game canvas has an offscreen buffer image that is associated
with the canvas. When you perform any graphics operations on the Graphics
object associated with the canvas, the graphics are actually drawn to
the offscreen buffer; nothing on the screen changes. A call to the flushGraphics()
method is what results in the offscreen buffer being drawn to the
screen in one single operation. Flushing the offscreen buffer doesn’t
change its contents or clear it; it just paints the buffer to the
When you first create a GameCanvas object, the offscreen buffer is initially filled with all white pixels.
class includes a few other interesting features that come in handy for
mobile games, such as efficient key input processing. For now, however, you know enough to use the GameCanvas class to create a smooth little animation MIDlet.