Ответ 1
1)
Пока аппаратное ускорение никогда не включено по умолчанию, и, насколько мне известно, он еще не изменился. Чтобы активировать ускорение рендеринга, передайте этот аргумент (-Dsun.java2d.opengl = true) в Java-пуск при запуске программы или установите его перед использованием любых библиотек рендеринга. System.setProperty("sun.java2d.opengl", "true"); Это необязательный параметр.
2)
Да BufferedImage инкапсулирует некоторые детали управления энергозависимой памятью, потому что, когда ускоряется BufferdImage, его копия сохраняется в V-Ram как VolatileImage.
Поверхность к BufferedImage до тех пор, пока вы не возитесь с пикселями, которые она содержит, просто скопируйте их как вызов graphics.drawImage(), затем BufferedImage будет ускорен после определенного не определенного числа копий, и он будет управлять VolatileImage для вас.
Недостатком BufferedImage является то, что вы выполняете редактирование изображений, меняя пиксели в BufferedImage, в некоторых случаях он откажется от попытки ускорить его, в этот момент, если вы ищете рендеринг для рендеринга для вам необходимо рассмотреть возможность управления вашим собственным VolatileImage. Я не знаю, какие операции заставляют BufferedImage отказаться от попыток ускорить рендеринг для вас.
3)
Преимущество использования createCompatibleImage()/createCompatibleVolatileImage()
заключается в том, что ImageIO.read() не делает никакого преобразования в поддерживаемую по умолчанию Image Data Model.
Поэтому, если вы импортируете PNG, он будет представлять его в формате, создаваемом программой PNG. Это означает, что каждый раз, когда он отображается с помощью GraphicsDevice, он должен быть сначала преобразован в совместимую модель данных изображения.
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, которое имеет модель данных изображения, совместимую с устройством экрана по умолчанию, так что преобразование не обязательно должно выполняться, когда оно будет отображаться. Время, когда это наиболее выгодно, - это когда вы будете очень часто показывать изображение.
4) Вам не нужно прилагать усилия для пакетной рендеринга изображений, потому что по большей части Java попытается сделать это за вас. Нет причин, по которым вы не можете сделать это, но в целом лучше профилировать свои приложения и подтвердить, что в коде рендеринга изображения есть узкое место, прежде чем пытаться выполнить такую оптимизацию производительности. Основным недостатком является то, что он будет реализован немного по-разному в каждой JVM, а затем улучшения могут оказаться бесполезными.
5)
Насколько я знаю, дизайн, который вы наметили, является одной из лучших стратегий при выполнении двойной буферизации вручную и активной визуализации приложения.
http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html
По этой ссылке вы найдете описание BufferStrategy. В описании он показывает фрагмент кода, который является рекомендуемым способом для активного рендеринга с объектом BufferStrategy. Я использую эту технику для своего активного кода рендеринга. Единственное существенное отличие в том, что в моем коде. как вы, я создал BufferStrategy в экземпляре Canvas, который я положил на JFrame.