Double buffering or Back to the past. Part two

Good day!

Introduction

It's already the fourth of January, and my soul won't stop kicking. So I decided to continue the theme of writing J2ME apps. Plus, several people expressed serious interest in this subject. And it was not only ordinary users of Habra, but read-only accounts. Well, okay, closer to the subject.
Almost immediately after the publication of Topeka, was received very good comments from abrowser barker, namely comment, in fact, a truism, and the second review — amendment, not less worthwhile.

what should we talk About today

Today we will talk about the process of double buffering in the javax.microedition.lcdui.Canvas and why were you created the javax.microedition.lcdui.game.GameCanvas.

What "double-buffering"

Double buffering is nothing but a technique which provides for the use of a second (off-screen) buffer to render the shapes, sprites and so on in it, and then copying its contents to screen. The problem is that when drawing directly, i.e. drawing directly to the screen buffer at the time not within the period of time the screen redraw (Canvas is repaint()) and the screen just starts "flashing", ie the user sees an intermediate result of the drawing. The use of this technique allows the developer to avoid these "flashes". However, in Canvas using this technique is the process of velosipedisty, because the developers of the standard and platform J2ME does not care about it.

"Double buffering" in Canvas

Is the process "double buffering" in Canvas is through the use of the image (object Image package javax.microedition.lcdui) in an offscreen buffer. Here it is:
the

import javax.microedition.lcdui.Canvas;
import javax.microedition.lcdui.Graphics; /* import needed for the library */
import javax.microedition.lcdui.Image;

public class OurCanvas extends Canvas {

Image img; // our Image
Graphics buf; // here is the buffer
int w; // screen height
int h; // width

public OurCanvas() { // Lego

w = getWidth(); // find out the height of the screen
h = getHeight(); // width

// first check that it supports "double buffering" by the device itself
// if Yes, then takes care of creating the second buffer we don't need
// if not, create Image
if (!isDoubleBuffered()) {
buffer = Image.createImage(w,h);
}

// get the ability to draw in the img
buf = img.getGraphics();
}

// draw in our buffer
public void draw(Graphics g) {
g.setColor(0xffffff);
g.fillRect(0,0,w,h);
g.setColor(0x111111);
g.fillRect(25,25,125,125);
g.setColor(0xababab);
g.fillRect(70,60,70,60);
}

public void paint(Graphics g) {
g.drawImage(0,0,w,h); // draw the buffer itself
draw(buf); // draw to buffer
}
}

That's all. The code contains more than obvious comments, so the parsing code should not cause you problems. Now consider the "double buffering" in the GameCanvas.

"Double buffering" in GameCanvas

Some time passed and J2ME consortium has developed a package javax.microedition.lcdui.game containing GameCanvas, which was the same Canvas, but already solved the problem of "double buffering". Programmers no longer need to take care of her. The code will look like the following:
the

import javax.microedition.lcdui.game.GameCanvas;
import javax.microedition.lcdui.Graphics; /* import needed for the library */
import javax.microedition.lcdui.Image;

public class OurCanvas extends GameCanvas implements Runnable {

Graphics buf;
Thread t;
int w; // screen height
int h; // width

public OurCanvas() { // constructor of our OurCanvas

w = getWidth(); // find out the height of the screen
h = getHeight(); // width

// get a reference to the Graphics object
buf = getGraphics();

// our thread
t = new Thread(this);
}

// let's draw
public void run {
g.setColor(0xffffff);
g.fillRect(0,0,w,h);
g.setColor(0x111111);
g.fillRect(25,25,125,125);
g.setColor(0xababab);

flushGraphics(); // this is our "double-buffering"
}
}

Here we do not need to worry about buffer — all immediately drawn to it, and then when you call flushGraphics all the contents of the offscreen buffer is copied to screen.

all

Despite the fact that this problem is solved by drawing a few lines — it is an important topic that developers can't "swim". I hope today's lesson was no less instructive than last. That's all, I'll take my leave.

See you soon!

Drink coffee, write in Java.

Post Scriptum

Source traditionally, you can pick up on Pastebin.
Here, first example.
Here — second.

Article based on information from habrahabr.ru