Почему рисование на JFrame намного медленнее, чем на JPanel?
Мой вопрос: ПОЧЕМУ та же самая процедура рисования с использованием свинга почти в 16 раз быстрее при рисовании на JPanel по сравнению с непосредственно на JFrame? Это просто двойная буферизация? Не может быть, конечно?
Фон: у меня была проблема с тем, что пользовательская живопись не обновлялась, когда JFrame не был скрыт (особенно после того, как он был частично скрыт). После поиска SO я решил укусить пулю и выяснить, как связать подкласс JPanel с формой конструктора bluddy-NetBeans-form.
Для тех, кто находится в такой же ситуации: в NetBeans вам нужно создать новый стандартный класс (НЕ форму JPanel), который просто расширяет JPanel, и вручную кодировать все, что там есть (без дизайнера графического интерфейса, например, good-ole-days, вздох). Затем вы добавляете стандартную JPanel в форму, устанавливаете ее размер; затем щелкните правой кнопкой мыши и выберите "Настроить код" и выберите "пользовательское создание" в поле со списком..., где он создает новый javax.swing.JPanel, заменяющий ваш подкласс.
Итак... Это позволило мне "сделать это правильно" и рисовать на компоненте, а не непосредственно на форме. Кроме того, Panel-Key-Listener гораздо более аккуратное решение, чем хай-джек фреймы Key-Event-Disatcher.
Так или иначе, теперь профилировщик говорит, что точно такой же пользовательский код рисования выполняется почти в 16 раз быстрее в paintComponent() JPanel, как и в paint() JFrame... и мне было интересно, если кто-нибудь может объяснить, почему.
Заранее спасибо. Кит.
РЕДАКТИРОВАТЬ: Этот вопрос основан на MISINTERPRETED METRICS. Профилировщик не включает / не сообщает метод paintComponent() JPanel в потоке AWT-EventQueue, где, поскольку мой базовый профиль действительно включает paint JFrame paint(). Я должен был посмотреть более внимательно, прежде чем задавать глупый вопрос. Виноват.
2 ответа
JFrame - это контейнер верхнего уровня, расширяющий aw.Frame, который требует собственных ресурсов для рисования, тогда как JPanel - это компонент колебания, который визуализируется самим потоком пользовательского интерфейса.
"Swing использует Java2D API для рисования, и в соответствии с этим руководством по поиску и устранению неисправностей Java SE 7, Java2D использует набор конвейеров рендеринга, " который можно грубо определить как различные способы рендеринга примитивов ". Более конкретно, конвейер рендеринга Java2D кажется подключить кроссплатформенный код Java к собственным графическим библиотекам (OpenGL, X11, D3D, DirectDraw, GDI), которые могут поддерживать аппаратное ускорение.
В Java 1.6.0_10 (он же 6u10) в Java2D для Windows был добавлен "полностью аппаратно ускоренный графический конвейер" на основе Direct3D для повышения производительности рендеринга в приложениях Swing и Java2D (включен по умолчанию).
По умолчанию, когда Java2D используется в системе Windows, этот конвейер Direct3D и конвейер DirectDraw/GDI включены по умолчанию (я предполагаю, что каждый из них используется для разных целей)."
Читайте дальше: Первый вызов конструктора JFrame занимает много времени во время запуска приложения Swing (из-за java.awt.Window())