Java 硬件加速 [英] Java Hardware Acceleration

问题描述

我花了一些时间研究 Java 的硬件加速功能，但我仍然有点困惑，因为我在网上直接找到的网站都没有明确回答我的一些问题.所以这里是我对 Java 硬件加速的问题:

I have been spending some time looking into the hardware acceleration features of Java, and I am still a bit confused as none of the sites that I found online directly and clearly answered some of the questions I have. So here are the questions I have for hardware acceleration in Java:

1) 在 Eclipse 3.6.0 版中，最新的 Java 更新为 Mac OS X(我认为是 1.6u10)，是否默认启用硬件加速?我在某处读到

1) In Eclipse version 3.6.0, with the most recent Java update for Mac OS X (1.6u10 I think), is hardware acceleration enabled by default? I read somewhere that

someCanvas.getGraphicsConfiguration().getBufferCapabilities().isPageFlipping()

应该指示是否启用了硬件加速，并且我的程序在我的主要 Canvas 实例上运行以进行绘图时报告为真.如果我的硬件加速现在没有启用，或者默认情况下没有启用，我需要怎么做才能启用它?

is supposed to give an indication of whether or not hardware acceleration is enabled, and my program reports back true when that is run on my main Canvas instance for drawing to. If my hardware acceleration is not enabled now, or by default, what would I have to do to enable it?

2) 我在这里和那里看到了几篇关于 BufferedImage 和 VolatileImage 之间区别的文章，主要是说 VolatileImage 是硬件加速图像，存储在 VRAM 中用于快速复制操作.但是，我也发现了一些 BufferedImage 也被认为是硬件加速的实例.BufferedImage 硬件是否也在我的环境中加速?如果两种类型都经过硬件加速，使用 VolatileImage 的优势是什么?我对在两者都有加速的情况下拥有 VolatileImage 的优势的主要假设是 VolatileImage 能够检测到其 VRAM 何时被转储.但是如果BufferedImage现在也支持加速了，是不是也内置了同样的检测，只是对用户隐藏，以防内存被转储?

2) I have seen a couple articles here and there about the difference between a BufferedImage and VolatileImage, mainly saying that VolatileImage is the hardware accelerated image and is stored in VRAM for fast copy-from operations. However, I have also found some instances where BufferedImage is said to be hardware accelerated as well. Is BufferedImage hardware accelerated as well in my environment? What would be the advantage of using a VolatileImage if both types are hardware accelerated? My main assumption for the advantage of having a VolatileImage in the case of both having acceleration is that VolatileImage is able to detect when its VRAM has been dumped. But if BufferedImage also support acceleration now, would it not have the same kind of detection built into it as well, just hidden from the user, in case that the memory is dumped?

3) 使用有什么好处

someGraphicsConfiguration.getCompatibleImage/getCompatibleVolatileImage()

相对于

ImageIO.read()

在一个教程中，我一直在阅读有关正确设置渲染窗口的一些一般概念(教程)它使用 getCompatibleImage 方法(我相信该方法会返回一个 BufferedImage)来获取硬件加速"图像以进行快速绘制，这与问题 2 是否为硬件加速有关.

In a tutorial I have been reading for some general concepts about setting up the rendering window properly (tutorial) it uses the getCompatibleImage method, which I believe returns a BufferedImage, to get their "hardware accelerated" images for fast drawing, which ties into question 2 about if it is hardware accelerated.

4) 这不是硬件加速，但这是我一直好奇的事情:我需要订购绘制哪些图形吗?我知道当通过 C/C++ 使用 OpenGL 时，最好确保在需要一次绘制的所有位置绘制相同的图形，以减少当前纹理需要切换的次数.从我所读到的内容来看，Java 似乎会为我解决这个问题，并确保以最佳方式绘制内容，但同样，从来没有像这样清楚地表达过任何东西.

4) This is less hardware acceleration, but it is something I have been curious about: do I need to order which graphics get drawn? I know that when using OpenGL via C/C++ it is best to make sure that the same graphic is drawn in all the locations it needs to be drawn at once to reduce the number of times the current texture needs to be switch. From what I have read, it seems as if Java will take care of this for me and make sure things are drawn in the most optimal fashion, but again, nothing has ever said anything like this clearly.

5) 哪些 AWT/Swing 类支持硬件加速，应该使用哪些类?我目前正在使用一个扩展 JFrame 的类来创建一个窗口，并向其中添加一个 Canvas，我从中创建了一个 BufferStrategy.这是好的做法，还是我应该采用其他类型的方法来实现这一点?

5) What AWT/Swing classes support hardware acceleration, and which ones should be used? I am currently using a class that extends JFrame to create a window, and adding a Canvas to it from which I create a BufferStrategy. Is this good practice, or is there some other type of way I should be implementing this?

非常感谢您抽出宝贵时间，我希望我提供了明确的问题和足够的信息，以便您回答我的几个问题.

Thank you very much for your time, and I hope I provided clear questions and enough information for you to answer my several questions.

推荐答案

1)到目前为止，默认情况下从未启用硬件加速，据我所知，它还没有改变.要激活渲染加速，请在程序启动时将此参数 (-Dsun.java2d.opengl=true) 传递给 Java 启动器，或在使用任何渲染库之前设置它.System.setProperty("sun.java2d.opengl", "true"); 可选参数.

1) So far hardware acceleration is never enabled by default, and to my knowledge it has not changed yet. To activate rendering acceleration pass this arg (-Dsun.java2d.opengl=true) to the Java launcher at program start up, or set it before using any rendering libraries. System.setProperty("sun.java2d.opengl", "true"); It is an optional parameter.

2)是的 BufferedImage 封装了管理易失性内存的一些细节，因为当 BufferdImage 加速时，它的一个副本作为 VolatileImage<存储在 V-Ram 中/代码>.

2) Yes BufferedImage encapsulates some of the details of managing the Volatile Memory because, when the BufferdImage is accelerated a copy of it is stored in V-Ram as a VolatileImage.

BufferedImage 的好处是只要你不弄乱它包含的像素，只需像调用 graphics.drawImage() 一样复制它们，然后BufferedImage 将在一定数量的非指定副本后加速，并为您管理 VolatileImage.

The upside to a BufferedImage is as long as you are not messing with the pixels it contains, just copying them like a call to graphics.drawImage(), then the BufferedImage will be accelerated after a certain non specified number of copies and it will manage the VolatileImage for you.

BufferedImage 的缺点是，如果你正在编辑图像，改变 BufferedImage 中的像素，在某些情况下它会放弃尝试加速它，在如果您正在为您的编辑寻找高性能渲染，那么您需要考虑管理自己的 VolatileImage.我不知道是哪些操作让 BufferedImage 放弃了为你加速渲染的尝试.

The downside to a BufferedImage is if you are doing image editing, changing the pixels in the BufferedImage, in some cases it will give up trying to accelerate it, at that point if you are looking for performant rendering for your editing you need to consider managing your own VolatileImage. I do not know which operations make the BufferedImage give up on trying to accelerate rendering for you.

3)使用createCompatibleImage()/createCompatibleVolatileImage()的优势是 ImageIO.read() 不会对默认支持的图像数据模型进行任何转换.因此，如果您导入 PNG，它将以 PNG 阅读器构建的格式表示它.这意味着每次由 GraphicsDevice 渲染时，它必须首先转换为兼容的图像数据模型.

3) The advantage of using the createCompatibleImage()/createCompatibleVolatileImage() is that ImageIO.read() does not do any conversion to a default supported Image Data Model. So if you import a PNG it will represent it in the format built by the PNG reader. This means that every time it is rendered by a GraphicsDevice it must first be converted to a compatible Image Data Model.

BufferedImage image = ImageIO.read ( url );
BufferedImage convertedImage = null;
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment ();
GraphicsDevice gd = ge.getDefaultScreenDevice ();
GraphicsConfiguration gc = gd.getDefaultConfiguration ();
convertedImage = gc.createCompatibleImage (image.getWidth (), 
                                           image.getHeight (), 
                                           image.getTransparency () );
Graphics2D g2d = convertedImage.createGraphics ();
g2d.drawImage ( image, 0, 0, image.getWidth (), image.getHeight (), null );
g2d.dispose()

上述过程会将使用图像 io api 读取的图像转换为具有与默认屏幕设备兼容的图像数据模型的 BufferedImage，以便在渲染时无需进行转换.最有利的时候是您将非常频繁地渲染图像.

The above process will convert an image read in with the image io api to a BufferedImage that has a Image Data Model compatible with the default screen device so that conversion does not need to take place when ever it is rendered. The times when this is most advantageous is when you will be rendering the image very frequently.

4)您无需努力对图像渲染进行批处理，因为在大多数情况下 Java 会尝试为您执行此操作.您没有理由不尝试这样做，但通常最好先分析您的应用程序并确认图像渲染代码存在瓶颈，然后再尝试执行诸如此类的性能优化.主要缺点是它在每个 JVM 中的实现略有不同，因此增强可能毫无价值.

4) You do not need to make an effort to batch your image rendering because for the most part Java will attempt to do this for you. There is no reason why you cant attempt to do this but in general it is better to profile your applications and confirm that there is a bottleneck at the image rendering code before you attempt to carry out a performance optimization such as this. The main disadvantage is that it my be implemented slightly differently in each JVM and then the enhancements might be worthless.

5)据我所知，您所概述的设计是手动执行双缓冲并主动呈现应用程序时更好的策略之一.http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html在此链接中，您将找到 BufferStrategy 的描述.在描述中，它显示了一个代码片段，这是使用 BufferStrategy 对象进行主动渲染的推荐方式.我将这种特殊技术用于我的活动渲染代码.唯一的主要区别是在我的代码中.和你一样，我在一个 Canvas 的实例上创建了 BufferStrategy，我把它放在了 JFrame 上.

5) To the best of my knowledge the design you have outlined is one of the better strategies out there when doing Double Buffering manually and actively rendering an application. http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html At this link you will find a description of the BufferStrategy. In the description it shows a code snippet that is the recommended way to do active rendering with a BufferStrategy object. I use this particular technique for my active rendering code. The only major difference is that in my code. like you, I have created the BufferStrategy on an instance of a Canvas which I put on a JFrame.

这篇关于Java 硬件加速的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！