Графика буферной стратегии Java или целочисленный массив

Давайте проясним одну вещь: оба фрагмента кода делают одно и то же — рисуют изображение. Однако фрагменты довольно неполные — второй фрагмент не показывает, что такое «testImage.image» на самом деле или как он создается. Но они оба в конечном итоге вызывают Graphics.drawImage(), и все варианты drawImage() в Graphics или Graphics2D рисуют изображение, простое и понятное. Во втором случае мы просто не знаем, является ли это изображением BufferedImage, VolatileImage или даже изображением Toolkit.

Таким образом, нет никакой разницы в том, что на самом деле проиллюстрировано здесь!

Между этими двумя фрагментами есть только одно различие: первый также получает прямую ссылку на целочисленный массив, который в конечном итоге внутренне поддерживает экземпляр Image. Это дает прямой доступ к данным пикселей вместо того, чтобы проходить через API (буферизованного) изображения с использованием, например, относительно медленных методов getRGB() и setRGB(). Причина, по которой это нельзя сделать конкретным в контексте, заключается в этом вопросе, массив получен, но никогда не используется во фрагменте. Таким образом, чтобы дать следующему объяснению какую-либо причину существования, мы должны сделать предположение, что кто-то хочет напрямую читать или редактировать пиксели изображения, вполне возможно, по причинам оптимизации, учитывая «медлительность» API (буферизованного) изображения для манипулировать данными.

И эти причины оптимизации могут быть преждевременной оптимизацией, которая может иметь для вас неприятные последствия.

Во-первых, этот код работает только потому, что тип изображения — INT_RGB, что дает изображению IntDataBuffer. Если это был образ другого типа, например 3BYTE_BGR, этот код завершится с ошибкой ClassCastException, поскольку резервный буфер данных не будет IntDataBuffer. Это может не быть большой проблемой, когда вы создаете изображения только вручную и применяете определенный тип, но изображения, как правило, загружаются из файлов, созданных внешними инструментами.

Во-вторых, есть еще один большой недостаток прямого доступа к пиксельному буферу: когда вы это сделаете, Java2D откажется от ускорения этого изображения, поскольку он не может знать, когда вы будете вносить в него изменения вне его контроля. Просто для ясности: ускорение — это процесс хранения неизмененного изображения в видеопамяти, а не копирование его из системной памяти каждый раз при отрисовке. Это потенциально огромное улучшение производительности (или потеря, если вы его сломаете) в зависимости от того, с каким количеством изображений вы работаете.

Как создать образ с аппаратным ускорением с помощью Java2D?

(Как показывает этот связанный вопрос: вы должны использовать GraphicsConfiguration.createCompatibleImage() для создания экземпляров BufferedImage).

Итак, по сути: старайтесь использовать API Java2D для всего, не обращайтесь к буферам напрямую. Этот внешний ресурс дает хорошее представление о том, какие функции API должен поддерживать вас в этом, не переходя на более низкий уровень:

http://www.pushing-pixels.org/2008/06/06/efficient-java2d.html

Во-первых, много исторических аспектов. Ранний API был очень простым, поэтому единственным способом сделать что-то нетривиальное было реализовать все необходимые примитивы.

Доступ к необработанным данным немного устарел, и мы можем попытаться провести некоторую «археологию», чтобы найти причину, по которой использовался такой подход. Я думаю, что есть две основные причины:

<сильный>1. Эффекты фильтра

Не будем забывать, что эффекты фильтров (разного рода размытия и т. д.) просты, очень важны для любого разработчика игр и широко используются.

Самый простой способ реализовать такой эффект в Java 1 заключался в использовании массива int и фильтра, определенного как матрица. У Герберта Шильдта, например, было много таких демонстраций:

public class Blur {

    public void convolve() {
        for (int y = 1; y < height - 1; y++) {
            for (int x = 1; x < width - 1; x++) {
                int rs = 0;
                int gs = 0;
                int bs = 0;
                for (int k = -1; k <= 1; k++) {
                    for (int j = -1; j <= 1; j++) {
                        int rgb = imgpixels[(y + k) * width + x + j];
                        int r = (rgb >> 16) & 0xff;
                        int g = (rgb >> 8) & 0xff;
                        int b = rgb & 0xff;
                        rs += r;
                        gs += g;
                        bs += b;
                    }
                }
                rs /= 9;
                gs /= 9;
                bs /= 9;
                newimgpixels[y * width + x] = (0xff000000
                        | rs << 16 | gs << 8 | bs);
            }
        }
    }
} 

Естественно, вы можете реализовать это с помощью getRGB, но доступ к необработанным данным намного эффективнее. Позже Graphics2D предоставил лучший уровень абстракции:

общедоступный интерфейс BufferedImageOp

Этот интерфейс описывает операции с одним вводом/выводом, выполняемые над объектами BufferedImage. Он реализуется AffineTransformOp, ConvolveOp, ColorConvertOp, RescaleOp и LookupOp. Эти объекты можно передать в BufferedImageFilter для работы с BufferedImage в парадигме ImageProducer-ImageFilter-ImageConsumer.

<сильный>2. Двойная буферизация

Другая проблема была связана с мерцанием и очень медленной прорисовкой. Двойная буферизация устраняет уродливое мерцание и внезапно предоставляет простой способ создания эффектов фильтрации, потому что у вас уже есть буфер.

Что-то вроде окончательного заключения :)

Я бы сказал, что описанная вами ситуация довольно типична для любой развивающейся технологии. Есть два способа достижения одних и тех же целей:

• использовать устаревший подход, больше кодировать и т. д.
• полагаться на новые уровни абстракции, предоставленные методы и т. д.

Также есть несколько полезных расширений, которые еще больше упростят вам жизнь, так что не нужно использовать int[] :)