Java BuffereImage与VolatileImage的当前状态

在实现窗口的快速图像绘制时，当前的最佳实践是什么？我说的是一些非常简单的东西，比如一个带有2缓冲区策略的JFrame。（目前）最快的方法是什么

我到处都读到，VolatileImage是硬件加速的，而BuffereImage是管理的，除了可能不再是，因为随着每次新的更新（+Java 7的发布），情况可能不再是这样，因为Java加速了越来越多的BuffereImage，等等

那么（一般而言），您对在以下条件下实施快速图像绘制有何建议：

• Java 6u33+或Java 7+
• 一个图像覆盖整个JFrame或多个小图像
• 图像透明度可以启用，也可以不启用，但必须足够容易地支持
• 如果它有助于考虑使用活动渲染的类似游戏循环的设置

在有人问我之前，我已经尝试对这两个进行基准测试，我发现我的硬件几乎没有什么不同。不过，我听说这可能也依赖于硬件，所以我只是在寻找现代最佳实践

是否有任何官方文件或基准可以帮助证明这一点

我不知道。但是，您可能会修改此Java 2D基准以比较这两种方法：

（关于Java基准测试的标准警告适用…

来自我移动的线程“BuffereImage vs VolatileImage-性能比较”（编辑并改进）：

介绍 我最近发现了一个关于VolatileImage的问题，与BuffereImage相比，它的性能非常好。我自己在我的一个项目中尝试过，它的优势似乎很明显！ 但尽管我很挑剔，我还是希望看到数字形式的结果，这就是我想到的：

---

标杆管理 我决定创建一个小程序，给我一些基准测试结果来比较不同条件下的两种图像类型

程序：基准方法很简单。一个2K（2560x1440）的测试图像被缩小到HD（1280x720），然后绘制到一个BuffereImage或一个VolatileImage上（我使用BuffereImage来存储测试图像，因为测试表明它与我存储它所使用的图像类型没有区别）。然后有两种变体： 1st在同一循环运行中，当测试图像被绘制到缓冲区或VolatileImage或缓冲区，或VolatileImage被绘制到帧的JPanel时。 2nd在将测试图像绘制到JPanel之前，测试图像在Volatile或buffereImage上绘制了n次。程序记录两个测试（第一个BuffereImage，第二个VolatileImage）的执行时间，并在控制台中打印出来。我还测试了如果使用相同的测试图片和alpha通道（透明度），结果会如何，因为我经常看到有人声称VolatileImage会有问题

结果：我在Mac Minit（2012年底）上运行了该程序，该程序采用2.5Ghz的Intel i5双核。使用的Java版本是v8_112，通过Eclipse执行。以下是我的结果：

Test-methodology 1 - no transparency:
  Num of Repeats:  BufferedImage:  VolatileImage:
   200              3.280 Seconds    0.784 Seconds
   500              8.230 Seconds    1.818 Seconds
   1000             16.030 Seconds   3.666 Seconds

Test-methodology 1 - transparancy:
  Num of Repeats:  BufferedImage:  VolatileImage:
   200              4.166 Seconds   0.806 Seconds
   500              10.636 Seconds  1.793 Seconds
   1000             20.565 Seconds  3.514 Seconds

Test-methodology 2 - no transparancy:
  Num of Repeats:  BufferedImage:  VolatileImage:
   200              1.165 Seconds   0.093 Seconds
   500              2.862 Seconds   0.104 Seconds
   1000             5.770 Seconds   0.112 Seconds

Test-methodology 2 - transparancy:
  Num of Repeats:  BufferedImage:  VolatileImage:
   200              2.389 Seconds   0.120 Seconds
   500              5.986 Seconds   0.128 Seconds
   1000             11.902 Seconds  0.134 Seconds

---

结论 当然，有关性能的很多信息取决于映像的实现和使用方式。在我的例子中，作为缓冲区，它允许我做一些事情，比如对整个图像进行淡入淡出。但是，您仍然可以找到这两种图像类型的一些重要的向下和向上方向：

通常，在测试中，VolatileImage似乎比BuffereImage快得多（4到6倍）。在一次非合成测试中，我在一个小游戏中使用了相同的实现，得到了类似的结果。但在我的测试中，我找到了一种实现方式（遗憾的是，我无法重建它），它向我表明，VolatileImage并不是永远都可以使用的方式（是的，在这种情况下，它比它的对手慢）

从透明度上看，两种图像类型的缩放都是均匀的，但VolatileImage似乎并没有像BuffereImage那样损失太多的速度，尽管添加了alpha通道

我想说的是：在我的测试中，循环次数很少（1-10次），我发现BuffereImage在绘制单个帧时要快得多。尤其是渲染透明图像时。单帧的BuffereImage约为0.03秒，VolatileImage需要0.035秒。当使用大约3到6次循环运行时，差距变得更大。只有在超过8到10秒时，VolatileImage才占据了整个领域，并且随着循环运行量的增加而变得更好

我想用你的观点（通过测试支持）来扩展这个结论，还想知道你提出的这两个图像的哪些实现，以及它们是如何变化的

就我个人而言，我将在将来使用VolatileImage进行渲染。BuffereImage将是我的日常驱动程序，用于存储在渲染循环中绘制的图像。主要是因为我发现它们更容易处理（有一种方法可以将BIs转换为VIs，但这是另一个时代的故事）。我也期待着Java9，它已经在今年12月发布了，但似乎被推迟了，并将再次运行我的测试

---

来源

---

我上传了我的。你可以看看它，如果你想，拉它，自己试试

BuffereImage和VolatileImage之间几乎没有什么区别，正如您所说，BuffereImage现在实际上是硬件加速的。此外，我还读到一些关于VolatileImage在全屏模式下速度较慢的信息，但我猜这可能是由硬件决定的。对。是否有任何官方文件或基准有助于证明这一点？我分叉了你的基准，几乎重写了它，以反映我认为是一个更“正常”的用例。在我的用例中，在写入屏幕之前，我不会执行N次写入缓冲区的循环-我会执行N次写入缓冲区的循环，然后再写入屏幕。通过更新的测试，BuffereImage非常有用