производительность Java рисования с прозрачным цветом?

Question

производительность Java рисования с прозрачным цветом?

1

Кто-нибудь знает, создает ли заполняющий прямоугольник полностью прозрачный цвет (alpha = 0)? Или он оптимизирован и полностью пропущен? Я говорю о коде, как это:

Graphics g;
....
g.setColor(new Color(0xFF,0xFF,0xFF,0x00));
g.fillRect(0, 0, width, height);    // <= does this take any CPU?

Ma99uS 04 фев. 2015, в 18:07

Источник

0

Поскольку Graphics - это абстрактный класс, вы не сможете ответить на этот вопрос, не указав версию Java, ОС и, возможно, аппаратные драйверы / ускорители.
ControlAltDel 04 фев. 2015, в 17:03
0

Я думаю, что это не оптимизировано. Если вам действительно любопытно, вы должны скомпилировать и проверить байт-код
ControlAltDel 04 фев. 2015, в 17:04
0

Его системная зависимость. На большинстве систем это будет выполняться с помощью действий визуализации Direct3D или OpenGL, а затем смешивание выполняется с помощью графического процессора. Но у вас нет гарантии, когда дело доходит до Java2D.
Gimby 04 фев. 2015, в 17:14

Показать ещё 1 комментарий

Теги:

java

awt

alpha-transparency

1 ответ

Ещё вопросы

Поскольку Graphics - это абстрактный класс, вы не сможете ответить на этот вопрос, не указав версию Java, ОС и, возможно, аппаратные драйверы / ускорители.
Я думаю, что это не оптимизировано. Если вам действительно любопытно, вы должны скомпилировать и проверить байт-код
Его системная зависимость. На большинстве систем это будет выполняться с помощью действий визуализации Direct3D или OpenGL, а затем смешивание выполняется с помощью графического процессора. Но у вас нет гарантии, когда дело доходит до Java2D.

Marco13 · Accepted Answer · 2015-02-04T16-33-00.000Z

_{Не уверен, что это можно рассматривать как "приемлемый" ответ, но, возможно, полезно хотя бы:}

Как указано в комментариях: это зависит.

Класс Java Graphics - очень толстый слой абстракции. Вы можете использовать его для рендеринга в каждой операционной системе, причем каждая JVM с каждой графической картой с каждым драйвером, и даже тогда, все еще, используя разные методы.

В качестве примера: на обычной машине Windows вы можете явно указать, хотите ли вы использовать графический конвейер с графическим контентом OpenGL или графический конвейер на основе Direct3D с флагами -Dsun.java2d.opengl или -Dsun.java2d.d3d. Это может привести к фактической g.fillRect вызова либо в конечном итоге в соответствующем D3DRenderer или OGLRenderer метода ^(*) - и оттуда, это дело водителя, чтобы выяснить, действительно ли он сделать что - то для этого вызова ( учитывая, что текущий цвет прозрачен).

Интересно, что в вашем комментарии сказано, что //<= does this take any CPU? , В большинстве случаев ЦП не заботится о прозрачности цвета или нет. Он просто переадресует вызов на конвейер рендеринга. Таким образом, в сомнении, он накладывает нагрузку на графический процессор.

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

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

if (color.getAlpha() > 0) paintMillionsOfRectangles();

чтобы избежать цикла, который выполняет миллионы вызовов g.fillRect, которые могут налагать более высокую вычислительную нагрузку (в частности: на ЦП), чем фактические операции, которые выполняются из-за вызовов fillRect (которые выполняются на аппаратном обеспечении, на графический процессор).

^{(*) Я не совсем уверен, действительно ли это правильные методы - снова слой абстракции очень толстый...}

Спасибо всем. Причина, по которой я задал этот вопрос, заключается в том, что мой профилировщик показывает g.fillRect как узкое место в моем приложении. (Он работает на эзотерическом встроенном Linux на низкоуровневом оборудовании с IBM JVM). Поэтому мне кажется, что перед заполнением мне нужна эта проверка для Alpha, так как это не похоже на то, что вызов оптимизирован в моей среде.