带有 Transparency.OPAQUE 的 createCompatibleImage 和带有 BufferedImage.TYPE_INT_ARGB 的简单 BufferedImage 构造函数有什么区别？

Question

版本 1 和版本 2 有什么区别？他们在我的情况下似乎也这样做，但我到处都读到版本 1 是更好的方法。但为什么？

public BufferedImage getImage(Icon icon) {
    int w = icon.getIconWidth();
    int h = icon.getIconHeight();

    // version 1
    GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
    BufferedImage image = gd.getDefaultConfiguration().createCompatibleImage(w, h, Transparency.OPAQUE);

    // version 2
    // BufferedImage image = new BufferedImage(w, h, BufferedImage.TYPE_INT_ARGB);

    Graphics2D g = image.createGraphics();
    icon.get().paintIcon(null, g, 0, 0);
    g.dispose();

    return image;
}

Answer 1

通常，第一种方法导致Image需要显示较少转换的 。

在最好的情况下，“第一种方法”图像将具有与实际屏幕内存布局完全相同的内存布局，这意味着为了在屏幕上显示图像，可以按原样复制图像数据。仅当屏幕内存布局为 ARGB（每个组件 8 位）时，“第二种方法”图像也是如此，并且在所有其他情况下，图像必须（对用户代码自动且透明地）转换为目标格式。

真实案例介于两者之间，可能涉及更多：

• 计算机可以有多个不同配置的图形设备（多个显卡）；
• 用户可以在程序运行时更改图形配置；
• 操作系统本身可以更改图形配置（想想 Win7 禁用或启用 Aero 的情况）。

理论上，每次Image格式和GraphicsConfiguration格式不兼容时，您都应该重新创建图像。

实际上，您可以使用new BufferedImage(w, h, BufferedImage.TYPE_INT_ARGB)（或任何其他适合您需要的特定图像类型），直到您可以证明正是使用 generic BufferedImages 导致您的应用程序运行缓慢（因为转换为目标设备格式）或消耗内存过多（因为转换需要额外的内存）。