【Swing基础】Java2D: 硬件加速 - 第一部分 - 非恒定图像类：Volatile Image
Java 1.4在Java 2D的功能方面引入了对硬件加速的支持。毫无疑问，硬件加速非常有用——不过有效的使用java.awt.image.VolatileImage至少要比使用传统的“图像缓冲”机制要复杂一些。仅当你在自行实现复杂的Java 2D渲染的时候，使用低级的“硬件加速”功能才是的确很重要的。如果你只是在使用比方说Swing里预编译的控件的话，那么这个技巧的大部分都不太合适。但是对那些Java的2D游戏编程的人，或者那些操作大量图形，如图表、图解的人来说，就非常有用了。
我假设这个技巧的读者至少熟悉双缓冲的概念——如果你不熟悉，请读这里。简短地说，双缓冲就是把渲染的过程推迟在“画面外”的缓冲里，然后快速地把缓冲复制到画面设备上，从而提高了画质（画面渲染得更柔和）。标准双缓冲的简单实现方式（没有硬件加速），代码基本如下：
// 也可以扩展其它类 - 不过通常会选择Canvas。
public class CustomGUI extends Canvas {
private Image offscreenImage;
private Graphics offscreenGraphics;
private Dimension offscreenDimension;
// ...
public void paint(Graphics g) {
Dimension currentSize = getSize();
if(offscreenImage == null || !currentSize.equals(offscreenDimension)) {
// 调用java.awt.Component.createImage(...)方法以获得Image对象
offscreenImage = createImage(currentSize.width, currentSize.height);
offscreenGraphics = offscreenImage.getGraphics();
offscreenDimension = currentSize;
}
// 渲染代码放在这里（使用offscreenGraphics的Graphics对象）
// 算法假设背景会被重新填充因为这里重用了Image对象
// （否则的话要从之前的渲染中取回背景）
offscreenGraphics.setColor(Color.WHITE);
offscreenGraphics.fillRect(0, 0, offscreenDimension.width, offscreenDimension.height);
offscreenGraphics.setColor(Color.BLACK);
offscreenGraphics.drawLine(0, 0, 10, 10); // 任意的渲染逻辑
// 把缓冲画回主Graphics对象
g.drawImage(offscreenImage, 0, 0, this);
}
public void update(Graphics g) {
paint(g);
}
}
这类“双缓冲”的情况是使用硬件加速最好的例子。然而现在问题变成了，如何使用java.awt.image.VolatileImage类来加速这里的代码？哦，以下的是改编自VolatileImage的Javadoc和Java关于volatile image的白皮书（深入理解阅读的强烈推荐）——上面那个类的新版本使用了VolatileImage做渲染——不用着急，我稍后会解释这段“离奇”的代码：
// 也可以扩展其它类 - 不过通常会选择Canvas。
public class CustomGUI extends Canvas {
private VolatileImage volatileImg;
// ...
public void paint(Graphics g) {
// 创建硬件加速图像
createBackBuffer();
// 主渲染循环。VolatileImage对象可能失去内容。
// 这个循环会不断渲染（如果需要的话并制造）VolatileImage对象
// 直到渲染过程圆满完成。
do {
// 为该控件的Graphics配置验证VolatileImage的有效性。
// 如果VolatileImage对象不能匹配GraphicsConfiguration
// （换句话说，硬件加速不能应用在新设备上）
// 那我们就重建它。
GraphicsConfiguration gc = this.getGraphicsConfiguration();
int valCode = volatileImg.validate(gc);
// 以下说明设备不匹配这个硬件加速Image对象。
if(valCode==VolatileImage.IMAGE_INCOMPATIBLE){
createBackBuffer(); // 重建硬件加速Image对象。
}
Graphics offscreenGraphics = volatileImg.getGraphics();
offscreenGraphics.setColor(Color.WHITE);
offscreenGraphics.fillRect(0, 0, getWidth(), getHeight());
offscreenGraphics.setColor(Color.BLACK);
offscreenGraphics.drawLine(0, 0, 10, 10); // 任意的渲染逻辑
// 把缓冲画回主Graphics对象
g.drawImage(volatileImg, 0, 0, this);
// 检查内容是否丢失
} while(volatileImg.contentsLost());
}
// 以下创建新的VolatileImage对象
private void createBackBuffer() {
GraphicsConfiguration gc = getGraphicsConfiguration();
volatileImg = gc.createCompatibleVolatileImage(getWidth(), getHeight());
}
public void update(Graphics g) {
paint(g);
}
}
呼——越来越复杂了。长话短说，VolatileImage只不过就是像名字所暗示的那样——易变化。VolatileImage可以被认为是在非标准内存（就是说显卡内存）中表达图像。这使得它们依赖于下层的硬件（显卡）特征，不是所有的时候都被激活，所以图像也可能或可能不被应用（表现在显卡没有使用的内存上）。这正是执行VolatileImage.IMAGE_INCOMPATIBLE检查的原因。我们要求VolatileImage对象验证自身在当前控件的GraphicsConfiguration中的有效性（请记住GraphicsConfiguration其核心代表了我们控件的目标“设备”），如果不匹配，我们就为当前GraphicsConfiguration（也就是当前显卡实例）重建VolatileImage。
除了外部的“有效性”检测之外，我们还恶心地（并罕见地）使用了do-while循环。有两个理由可以说明为何所有的逻辑被包裹在do-while循环中。第一，在我们已经开始渲染VolatileImage对象之后，图像可能再次变得不匹配。这种情况下，contentsLost()方法将返回true以让我们知道出问题了。第二，某些平台（我不指名）可能会出现显示内存“丢失”（BIU！哪去了？），这种情况需要你重写这块内存的所有数据。这种情况下VolatileImage.validate(...)返回的valCode实际上是VolatileImage.IMAGE_RESTORED（一共有三种结果——IMAGE_OK，IMAGE_RESTORED，IMAGE_INCOMPATIBLE）。而上面的代码的方案中，这个返回类型不需要显式地处理。通常，如果图像内容在上一次调用VolatileImage.validate(...)之后因为上述原因丢失，那么VolatileImage.contentsLost()返回true。也由于我强调的这种区别，我们的代码仅仅在每次循环中执行两次检验：在渲染逻辑之前调用VolatileImage.validate()（确保我们的图像对象可用），以及渲染逻辑之后的VolatileImage.contentsLost()调用，以确定我们上一次验证之后的图像都还在（表明我们调用validate之后所有的渲染逻辑都如预期所致）。
不要转台，我明天将秀给你看如何使用java.awt.image.BufferStrategy类隐藏这些疯狂的代码。