Материал: Портянкин И. Swing

дит до данного события, оно выполняется и вызывает метод все того же RepaintManager с названием paintDirtyRegions(). Опуская детали реализации, мы приходим к тому, что вызывается метод, определенный в базовом классе JComponent под названием paintImmediately(). Ну а в нем все уже совсем просто. В итоге методом getGraphics() создается графический объект и вызывается хорошо знакомый нам метод paint(). Работу этого метода в Swing мы подробно изучили чуть ранее, и все выполняется по той самой диаграмме, что мы составили. В результате компонент Swing перерисовывается, причем лишь один раз за определенный промежуток времени, и максимально оптимизировано.

Рисование в Swing: резюме

Подводя итоги всей системы рисования Swing, можно определить следующие самые важные выводы:

Метод paint() в Swing является частью внутренней системы и выполняет важную работу. Переопределять его для рисования компонента Swing не следует.

Для рисования компонента или просто графики применяется метод paint-

Component().

При рисовании в Swing необходимо учитывать свойство непрозрачности opaque. Если компонент непрозрачен, необходимо закрашивать его фон или не оставлять непрорисованных областей. Делается это либо вручную, либо вызовом super. paintComponent(), чтобы фон закрасил UI-представитель. Однако, второй способ не работает для компонентов, унаследованных напрямую от JComponent. Если не выполнить данное условие, мусор на экране неизбежен.

Перерисовка repaint() в Swing выполняется пакетами и оптимизируется. Если вас это не устраивает, придется переопределить или метод repaint(), или написать свой вариант класса RepaintManager. Впрочем, необходимости в этом практически не возникает.

Рисование «готовых» компонентов

Разбирая тонкости систем рисования библиотеки Swing и ее основы AWT, мы рассматривали все возникающие вопросы с точки зрения рисования с нуля, в пределах одного компонента, как это обычно и бывает. Однако легко себе представить и другую ситуацию — стандартные компоненты Swing весьма функциональны и полезны, и у вас может возникнуть желание «прорисовать» какой-либо из них в своем собственном компоненте. К примеру, надписи JLabel умеют отображать многострочный текст формата HTML и изображения, представьте, что вам пришлось бы заниматься тем же самым самостоятельно при создании любого нового компонента. Интересно, что сложные компоненты Swing, такие как таблицы JTable, используют те же самые надписи для отображения своих ячеек или текста, так что идея неплоха.

При работе с обычными легковесными компонентами AWT представить себе процесс их прорисовки в рамках другого компонента легко —нужно всего лишь вызвать метод paint(), предварительно задав размер компонента и возможно поменяв какие-то графические параметры объекта Graphics. Компонент никогда не знает, кто вызывает его прорисовку, и должен выполнять ее независимо от этого. Однако в Swing картина немного другая.

Если вспомнить процесс прорисовки компонентов Swing, то легко увидеть, что все действия идут через объект RepaintManager, а сам компонент, если он находится в другом компоненте, «подневолен» и настроен рисовать себя через буфер своего

компонента-предка. Если мы создадим новый компонент Swing, не добавляя его на экран, он увидит, что предков у него нет, и решит, что является первым компонентом в иерархии компонентов, пытаясь нарисовать себя через объект RepaintManager и экранный буфер. Так как компонент на самом деле на экране не находится, то и содержимое буфера скопировать будет некуда и прорисовка не получится. В этом случае компоненты Swing приходится настраивать дополнительно: отключать для таких компонентов двойную буферизацию. Тогда они рисуют себя напрямую и появляются на экране.

Интересно, что в свежих версиях JDK отключение буферизации не требуется, так как она и так отключена и заменена на буферизацию системного уровня. Однако

втом случае, если системная буферизация будет недоступна, стоит отключать буферизацию компонентов Swing, которые мы хотим рисовать на экране, но не добавлять

вконтейнеры.

Рассмотрим небольшой пример с прорисовкой компонентов:

//PaintingOtherComponents.java

//Прорисовка других компонентов как изображений import javax.swing.*;

import java.awt.*;

public class PaintingOtherComponents extends JFrame { public PaintingOtherComponents() {

super("PaintingOtherComponents"); setDefaultCloseOperation(EXIT_ON_CLOSE); add(new CustomPaintComponent()); setSize(400, 300);

setVisible(true);

}

class CustomPaintComponent extends JPanel { // кнопка для прорисовки

private JButton button = new JButton("Привет!"); // метод для рисования в Swing

protected void paintComponent(Graphics g) {

//необходимо вызвать для обработки свойства opaque super.paintComponent(g);

//рисуем кнопки

Graphics2D g2 = (Graphics2D) g; button.setSize(80, 30);

//отключение двойной буферизации — не всегда нужно button.setDoubleBuffered(false);

//переместим позицию рисования

g2.translate(100, 100); for (int i=1; i<=8; i++) {

// кручение кнопки по кругу g2.rotate(2*Math.PI / i);

а нарисовать уже этот вспомогательный контейнер. Вдобавок к стандартному рисованию этот контейнер к тому же отключает всю проверку корректности и дополнительную перерисовку, которую могут производить сложные компоненты Swing. Если компонент рисуется часто, стоит предпочесть именно этот способ. Мы еще не раз вспомним про него, когда будем обсуждать отображающие объекты (renderer) для сложных компонентов Swing.

Рисование вне рамок

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

Специального решения на этот случай в Swing не предусмотрено, однако мы можем воспользоваться побочными эффектами реализации библиотеки, применяя особые компоненты, такие как многослойные (layered pane) и прозрачные панели (glass pane), существующие в каждом окне Swing-приложений или апплете. В главе 6 мы рассмотрим их вместе со способами применения для создания эффектной графики .

RepaintManager как прикладной инструмент

Подводя итоги рассмотрения механизмов рисования Swing, мы видим, какую серьезную роль играет в них класс RepaintManager. Весь процесс рисования компонентов Swing, благодаря особой реализации базового класса JComponent, проходит через его двойную буферизацию, он также полностью заведует программной перерисовкой компонентов, оптимизируя ее. С этой точки зрения он всего лишь внутренний «винтик» Swing, однако с учитом того, что все «нити» при рисовании сходятся в одно место, мы получаем уникальную возможность вмешаться в рабочий процесс рисования, так как можем заменить экземпляр класса RepaintManager на свой собственный, методом setCurrentManager().

Прежде чем задуматься о собственной реализации, важно узнать, какие дополнительные реализации этого класса уже существуют. Прежде всего, это инструменты, которые мы обсуждали в предыдущей главе, для слежения за тем, чтобы все рисование в Swing велось из потока рассылки событий. Обращение к экземпляру класса RepaintManager из другого потока сразу же обозначает ошибку программиста и необходимость вынести вызывающий код в поток рассылки событий. Настолько же интересно применяет свой экземпляр класса RepaintManager библиотека вспомогательных инструментов SwingX. В ней существует панель, позволяющая настроить уровень прозрачности, как свой, так и всех содержащихся в ней компонентов. Однако, как мы знаем, при необходимости компоненты сами перерисовывают друг друга, и со стороны никак нельзя «заставить» их рисовать себя полупрозрачными. Решением является особый объект RepaintManager, который при запросе на перерисовку компонентов, находящихся в прозрачной панели, направляет их самой полупрозрачной панели так, чтобы она смогла настроить все параметры рисования и только потом нарисовать потомков.

Таким образом, можно использовать свой объект RepaintManager для контроля каких-либо критичных параметров в процессе рисования или же определять, какой