|
В Java Standard Edition 6 (Java SE 6) добавлен и расширен ряд полезных возможностей для разработчиков настольных приложений на Java.
Новые и обновленные функциональные возможности Java SE 6, Часть 1.
Роберт Экштейн, Февраль 2007
Содержание
* Заставка (Splash Screen)
* Панель быстрого запуска (System Tray)
* Победа над серым прямоугольником
* Текст на ЖК-мониторе
* Отрисовка в едином потоке
* Системный Look and Feel
* Взгляд вперед
В последнем выпуске платформы Java Standard Edition 6 (Java SE 6) были
добавлены или же расширены некоторые функциональные возможности для
разработчиков настольных приложений на Java. Обратите внимание, что в
ряде предыдущих статей, технических руководств и записей на блогах
обсуждались эти изменения, данная статья не только включает в себя
основное содержание каждого ресурса, но и обновляет его согласно
изменениям, включенным в заключительный выпуск Java SE 6.
Заставка (Splash Screen)
Из статьи " Новая функциональность заставки в Java SE 6" Олега Семенова и Даны Нури
Заставка является стандартной частью любого приложения с современным
графическим интерфейсом. До выпуска Java SE 6 вы могли использовать
Swing или AWT (Abstract Window Toolkit) для создания заставки в
приложениях, написанных на Java. Тем не менее, заставка могла быть
показана лишь после того, как приложение загрузило и инициализировало
виртуальную машину Java, AWT, обычно Swing и, возможно, ряд библиотек,
необходимых для работы приложения. Результатом является задержка в
несколько секунд. Поэтому заставка с использованием технологий Java
зачастую не оправдывала возложенных на нее ожиданий.
Java SE 6 предлагает решение данной проблемы, позволяя приложению
показывать заставку гораздо раньше, даже не дожидаясь старта
виртуальной машины. Теперь загрузчик Java приложения может декодировать
картинку и отображать ее в простом, недекорированном окне, как
представлено на рисунке 1.
Sample Splash Screen for a Java Technology Application
Рисунок 1. Пример заставки для приложения на Java
Показать собственную заставку можно двумя способами:
*
Если ваше приложение запускается из
командной строки или при помощи ярлыка, добавьте -splash: опцию
загрузчика Java приложений:
java -splash:filename.gif SplashTest
*
Если ваше приложение упаковано в JAR
файл, используйте опцию SplashScreen-Image в файле-манифесте. Поместите
картинку в JAR архив и укажите путь в опции. Например, вы можете
использовать следующий код в файле-манифесте manifest.mf:
Manifest-Version: 1.0
Main-Class: SplashTest
SplashScreen-Image: filename.gif
Интерфейс командной строки имеет приоритет перед настройками манифеста.
В некоторых случаях вы можете захотеть динамически обновлять заставку
во время показа. Можно использовать класс java.awt.SplashScreen для
того, чтобы закрыть окно заставки, сменить отображаемую картинку,
получить координаты или размер картинки и рисовать что-либо в окне
заставки. Обратите внимание, что вы не можете использовать класс
SplashScreen для создания заставки. Для этого вам следует использовать
опцию в командной строке или файле-манифесте.
The following code sample demonstrates the typical process for creating a splash screen.
SplashScreen splash = SplashScreen.getSplashScreen();
Graphics2D g = (Graphics2D)splash.createGraphics();
Dimension size = splash.getDimension();
g.setComposite(AlphaComposite.Clear);
g.fillRect(0, 0, size.width, size.height);
g.setPaintMode();
// Рисуем заставку.
g.update();
Первым делом получаем объект SplashScreen. Затем получаем графический
дескриптор при помощи метода createGraphics(). Далее получаем размер
окна заставки и убираем изображение. Это можно сделать, установив
смешанный режим AlphaComposite.Clear и нарисовав прямоугольник поверх
всего окна заставки. Далее вновь переходим в режим рисования и
отрисоваваем картинку заставки в графическом контексте. Наконец,
вызываем метод update() для того, чтобы показать результат.
Вы можете изменить картинку заставки, используя метод setImageURL()().
Если пользователь хочет закрыть окно заставки до того, как отобразится
первое окно AWT или Swing (или в тех редких случаях, когда ни AWT, ни
Swing не используется при создании графического интерфейса приложения),
можно сделать это при помощи метода SplashScreen.close().
Следующий пример демонстрирует возможности использования новой функциональности заставки.
import java.awt.*;
import java.awt.event.*;
public class SplashTest extends Frame implements ActionListener {
static void renderSplashFrame(Graphics2D g, int frame) {
final String[] comps = {"foo", "bar", "baz"};
g.setComposite(AlphaComposite.Clear);
g.fillRect(130,250,280,40);
g.setPaintMode();
g.setColor(Color.BLACK);
g.drawString("Loading "+comps[(frame/5)%3]+"...", 130, 260);
g.fillRect(130,270,(frame*10)%280,20);
}
public SplashTest() {
super("SplashScreen demo");
setSize(500, 300);
setLayout(new BorderLayout());
Menu m1 = new Menu("File");
MenuItem mi1 = new MenuItem("Exit");
m1.add(mi1);
mi1.addActionListener(this);
MenuBar mb = new MenuBar();
setMenuBar(mb);
mb.add(m1);
final SplashScreen splash = SplashScreen.getSplashScreen();
if (splash == null) {
System.out.println("SplashScreen.getSplashScreen() returned null");
return;
}
Graphics2D g = (Graphics2D)splash.createGraphics();
if (g == null) {
System.out.println("g is null");
return;
}
for(int i=0; i<100; i++) {
renderSplashFrame(g, i);
splash.update();
try {
Thread.sleep(200);
}
catch(InterruptedException e) {
}
}
splash.close();
setVisible(true);
toFront();
}
public void actionPerformed(ActionEvent ae) {
System.exit(0);
}
public static void main (String args[]) {
SplashTest test = new SplashTest();
}
}
Обратите внимание, что метод createGraphics() создает и возвращает
графический контекст - как объект Graphics для картинки, отображаемой
поверх окна заставки. Это позволяет вам рисовать поверх заставки.
Вместо того, чтобы рисовать на главном окне, вы рисуете на слое,
отображаемом поверх главного, используя альфа-сопряжение. Обратите
также внимание на то, что простое рисование в вышележащем слое не
вызывает принудительного обновления контента окна заставки. Вам следует
вызвать метод update() объекта класса SplashScreen, если вы хотите
добиться немедленного обновления.
Панель быстрого запуска
Из статьи " Новые возможности значков панели быстрого запуска в Java SE 6" Роберта Экштейна
Java SE 6 позволяет использовать значки в панели быстрого запуска при
помощи двух отдельных классов пакета java.awt: SystemTray и TrayIcon.
Эти классы предоставляют возможность добавить графику, всплывающее меню
и всплывающие подсказки к значку в панели быстрого запуска.
Панель быстрого запуска - это специальная область, обычно расположенная
в нижней части рабочего стола, из которой пользователи могут получить
доступ к запущенным приложениям. В случае рабочего стола Microsoft
Windows и Gnome на панель быстрого запуска часто ссылаются как на
область уведомления, тогда как в KDE - как на область быстрого запуска.
В каждой из систем все запущенные настольные приложения разделяют
данную область.
Рисунки 2 и 3 демонстрируют панель быстрого запуска для Windows и
Gnome. В обоих случаях панель расположена в правом нижнем углу экрана.
Windows System Tray
Рисунок 2. Область уведомления в системе Windows
Gnome System Tray
Рисунок 3. Панель быстрого запуска в системе Gnome
Класс java.awt.SystemTray предоставляет интерфейс работы с панелью
бытрого запуска для настольных приложений. Получить доступ к панели
можно, вызвав статический метод SystemTray.getSystemTray(). Однако,
перед тем как это сделать, приложение всегда должно вызывать
статический метод SystemTray.isSupported(), для того, чтобы проверить
поддерживается ли данная функция. Если панель быстрого запуска не
реализована или не поддерживается на данной платформе, метод
isSupported() вернет false. Если приложение при этом попытается вызвать
getSystemTray(), метод бросит java.lang.UnsupportedOperationException.
Каждое Java приложение использует единственную сущность SystemTray.
Поэтому оно не способно создать свой собственный экземпляр класса
SystemTray и взамен этого должно получить существующий при помощи
метода getSystemTray().
SystemTray содержит одну или более TrayIcons, которые добавляются к
панели при помощи метода add() и удаляются методом remove() если в них
отпадает необходимость. Обратите внимание, что метод add() может
бросить AWTException если операционная система или сама Java во время
выполнения обнаружили, что иконка не может быть добавлена в панель
быстрого запуска. К примеру, AWTException может быть кинуто настольным
приложением X Windows в том случае, если панели быстрого запуска не
существует.
Следующий пример кода демонстрирует как можно получить доступ к панели быстрого запуска и произвести в ней нужные изменения:
final TrayIcon trayIcon;
if (SystemTray.isSupported()) {
SystemTray tray = SystemTray.getSystemTray();
Image image = Toolkit.getDefaultToolkit().getImage("tray.gif");
MouseListener mouseListener = new MouseListener() {
public void mouseClicked(MouseEvent e) {
System.out.println("Tray Icon - Mouse
clicked!");
}
public void mouseEntered(MouseEvent e) {
System.out.println("Tray Icon - Mouse
entered!");
}
public void mouseExited(MouseEvent e) {
System.out.println("Tray Icon - Mouse
exited!");
}
public void mousePressed(MouseEvent e) {
System.out.println("Tray Icon - Mouse
pressed!");
}
public void mouseReleased(MouseEvent e) {
System.out.println("Tray Icon - Mouse
released!");
}
};
ActionListener exitListener = new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("Exiting...");
System.exit(0);
}
};
PopupMenu popup = new PopupMenu();
MenuItem defaultItem = new MenuItem("Exit");
defaultItem.addActionListener(exitListener);
popup.add(defaultItem);
trayIcon = new TrayIcon(image, "Tray Demo", popup);
ActionListener actionListener = new ActionListener() {
public void actionPerformed(ActionEvent e) {
trayIcon.displayMessage("Action Event",
"An Action Event Has Been Performed!",
TrayIcon.MessageType.INFO);
}
};
trayIcon.setImageAutoSize(true);
trayIcon.addActionListener(actionListener);
trayIcon.addMouseListener(mouseListener);
try {
tray.add(trayIcon);
} catch (AWTException e) {
System.err.println("TrayIcon could not be added.");
}
} else {
// Панель бытрого запуска не поддерживается.
}
Победа над серым прямоугольником
Составлено из двух тем блога: " Оптимизация рендеринга в Swing: Нет
серым прямоугольникам!" Скота Вайлета и " Обновления в Swing: Нет серым
прямоугольникам!" Чета Хааса
При расмотрении различных проектов для JDK 6, имеющих отношение к
производительности, команда, занимающаяся разработкой Swing, решила
взяться за одну из давнишних проблем в Swing, вносящюю значительный
вклад в снижение производительности. Она именуется проблемой серого
прямоугольника и возникает в том случае, если приложение на базе Swing
отображается после того, как оно было перекрыто другим приложением. При
этом наблюдается вполне заметная пауза между очисткой фона окна и
завершением перерисовки актуального содержимого. В JDK 6 данная
проблема была решена.
Решение включило в себя добавление истинной двойной буферизации в
Swing. Это означает то, что теперь каждое окно приложения располагает
внеэкранной копией картинки, называемой обратным буфером и
синхронизированной с отображаемым окном. При обращении к окну, Swing
просто-напросто передает копию внеэкранной картинки экрану через
инструментальный поток. Дополнительный бонус данного решения в том, что
даже если ваше приложение блокирует поток управления событиями - к
примеру, если вы подоединяетесь к серверу, и в это время пользователь
прячет ваше окно и затем вновь раскрывает - приложение все равно сможет
перерисовать себя.
Первоначальный механизм буферизации в Swing был создан в то время,
когда системная память была ограниченным ресурсом, поэтому один
обратный буфер разделяли все окна Swing. Вместо типичного применения
буфера - как резервной копии содержимого экрана, буфер в Swing в
большей мере играл роль "рабочего буфера" для дожидающихся своей
очереди операций. Всякий раз при необходимости обновить одно из своих
окон, Swing должен был отрисовать нужный регион в верхней левой области
обратного буфера, а затем скопировать его в соответствующий участок
окна.
В результате содержимое обратного буфера было непостоянным и далеко не
вегда отражало содержимое окна Swing. Например, если другое окно было
протащено через окно Swing и заставило его обновить свой контент, Swing
должен был перерисовать одни и те же области вхождения много раз,
поскольку он не имел представления о том, что было в них ранее.
Благодаря новому подходу сейчас у каждого окна Swing на экране есть
свой собственный буфер, и содержимое этих буферов синхронизованно с
содержимым самого окна. Таким образом, если вы протащите окно через
окно Swing приложения, Swing сможет просто скопировать обратный буфер
на экран и сэкономить всю работу по очистке и перерисовке множества
областей.
К тому же Swing проводит данную операцию быстрого копирования в
собственном потоке обработки событий, что гарантирует незамедлительную
реакцию.
Рисунок 4 показывает относительные скорости валидаций окон NetBeans IDE с использованием различных выпусков JDK
NetBeans IDE Window Validations With Different JDK Releases
Рисунок 4. Валидация окон NetBeans IDE с использованием различных выпусков JDK
Текст на ЖК-мониторе
Из записи на блоге "Корректровка шрифтов от Фила" Чета Хааса и Фила Рейса
Одной из наиболее часто запрашиваемых функциональных возможностей JDK 6
была поддержка сабпиксельного текста. Это оптимизация для ЖК-мониторов,
позволяющая представить пиксел в виде набора полосок, что увеличивает
разрешение текста. Благодаря тому, что данное свойство может быть
применено и настроено пользователями, сабпиксельный текст часто
рассматривают как форму сглаживания текста
Хорошая новость - в JDK 6 включена данная функциональная возможность.
Независимо от того, используете ли вы стиль Metal, Microsoft Windows,
или GTK, вы обнаружите, что сглаживание шрифтов в приложениях,
базирующихся на Java технологиях, происходит одинаково - и при этом
аналогично тому, что происходит в <родных> приложениях. Наиболее
приятно то, что вы не должны что-либо делать - это работает само по
себе.
Для того достижения этого, стили Windows и GTK также были обновлены
таким образом, чтобы можно было отслеживать предпочтения пользователя в
отношении рабочего стола и применять необходимые изменения в реальном
времени. Стиль, применяемый в технологии Java по умолчанию, Metal,
теперь получает предпочтения пользователя касательно сглаживания текста
при загрузке и применяет их к шрифтам JDK. При исползовании стиля Metal
"Ocean" ", в котором жирные шрифты заменены на простые, результат
гораздо приятней для глаз, что показано на 5 рисунке.
Java Metalworks Demo
Рисунок 5. Демонстрационная программа Java Metalworks (Тема Ocean)
Нажмите здесь для получения полноразмерной картинки
Swing поддерживает 5 новых ключей java.awt.RenderingHints.KEY_TEXT_ANTIALIASING на всех платформах:
* VALUE_TEXT_ANTIALIAS_LCD_HRGB
* VALUE_TEXT_ANTIALIAS_LCD_HBGR
* VALUE_TEXT_ANTIALIAS_LCD_VRGB
* VALUE_TEXT_ANTIALIAS_LCD_VBGR
* VALUE_TEXT_ANTIALIAS_GASP
Первые четыре коррелируют с четыремя возможными ЖК-сабпиксельными
конфигурациями. Собственные приложения GTK поддерживают все из них. В
случае Windows, вам понадобится по крайней мере XP, чтобы получить
поддержку ЖК-текста в собственных приложениях, хотя Microsoft
поддерживает лишь HRGB в Windows XP, а поддержка HBGR добавлена
компанией в XP Service Pack 1 (SP1). JDK поддерживает ЖК-текст во всех
версиях Windows.
JDK использует последний ключ, VALUE_TEXT_ANTIALIAS_GASP, для того,
чтобы точно эмулировать "стандартное" сглаживание шрифтов в Windows -
это именно то, что нужно пользователям электронно-лучевых мониторов.
Обратите внимание, что при данной настройке не весь текст сглажен.
Вместо этого используется таблица для шрифта, называемая GASP таблицей,
задающей размеры, при которых следует проводить сглаживание.
Чтобы увидеть эффект, посмотрите на демонстрационную панель JTable из SwingSet2. На рисунке 6 - без ЖК-текста.
SwingSet2 Demo Without LCD Text
Рисунок 6. Демонстрационная программа SwingSet2 без ЖК-текста
Нажмите здесь для получения полноразмерной картинки
Рисунок 7 показывает то же самое с ЖК-текстом
SwingSet2 Demo With LCD Textgraphics7
Рисунок 7. Демонстрационная программа SwingSet2 с ЖК-текстом
Нажмите здесь для получения полноразмерной картинки
Снимок экрана на рисунке 8 демонстрирует тест с использование
одинаковых шрифтов так, как он был отрисован - программой Windows
WordPad слева и маленьким приложением JDK справа. Используемые здесь
шрифты можно видеть в типичных приложениях Windows.
LCD Fonts in WordPad and JDK
Рисунок 8. ЖК-шрифты в WordPad и JDK
Нажмите здесь для получения полноразмерной картинки
На рисунке 9 представлкен снимок экрана, на котором сравниваются
наиболее рапространенные шрифты, отрисованные в приложениях Gnome на
Linux, а также при помощи JDK. Текст Gnome был отрисован on Fedora Core
в gedit application. Поскольку gedit может использовать лишь один шрифт
в один момент, было сделано несколько снимков и слито воедино благодаря
GNU Image Manipulation Program (GIMP).
LCD Fonts Using gedit in Fedora Core
Рисунок 9. ЖК-шрифты с использованием gedit in Fedora Core
Нажмите здесь для получения полноразмерной картинки
Несколько замечаний:
*
Во-первых, данные изображения были
подготовлены для просмотра на жидкокристаллическом мониторе HRGB. Это
наиболее распространенный тип ЖК мониторов. Если вы используете
электронно-лучевой, не следует ожидать значительной оптимизации. Также
нужно отметить, что если ваш ЖК монитор, подсоединен через интерфейс
VGA вместо DVI, вы также не найдете существенных отличий. Интерфейс VGA
просто не обладает достаточно точной адресуемостью, неоходимой для
получения хорошего результата в данном случае.
*
Следующее замечание связано с тем, что
автоматическое масштабирование картинок в вашем браузере может изменить
сами картинки. Если они выглядят странно, попробуйте отключить
автоматическое масштабирование картинок или просто сохранить их, а
затем открыть локальным приложением для просмотра картинок.
Рендеринг в едином потоке
Составлено из двух записей в блоге: " Экстремальный STR: Оптимизация
конвеера Java 2D, использующего технологию OpenGL" и " Экстремальный
STR: Повышение производительности в JDK 6" Криса Кэмпбелла
До настоящего момента Java 2D отрисовывала графику в произвольных
потоках исполнения. При использовании рендеринга в едином потоке,
запросы образуют очередь на уровне платформы Java, а затем выпоняются
на уровне операционной системы в едином потоке. Однако данная
функциональная возможность не столь заметна, как многие другие в JDK 6.
В настоящий момент STR реализован лишь для конвейера рендеринга,
использующего OpenGL и, соответственно, не включенного по умолчанию для
ряда драйверов и аппаратных устройств.
Кроме того, что это крайне важно для перспектив развития программной
графики, STR предлагает существенную оптимизацию как для текущего
конвейера OpenGL, так и для будующих конвейеров рендеринга, желающих
использовать данный подход.
Таким образом у рендеринга в OpenGL появляются сразу два преимущества:
повышение устойчивости (так как мультипоточный рендеринг может быть
проблематичен в случае нескольких видеокарт) и повышение
производительности (так как собирание в пакет запросов на рендеринг
позволяет значительно снизить потери как в Java Native Interface (JNI),
так и в программном интерфейсе OpenGL). Вероятно, в дальнейших выпусках
Java SE подход STR будет использоваться и для других конвейеров
рендеринга (например, DirectX , по умолчанию работающий на платформе
Windows) и предоставлять аналогичный набор преимуществ.
Как известно большинству разработчиков, JDK 5.0 включил в себя
основанный на OpenGL Java 2D конвейер для того чтобы повысить скорость
рендеринга. Однако, хотя конвейер OGL оказался большим шагом вперед в
отношении производительности таких сложных операций, как трансформация,
композиция и градиенты, он был далеко не так надежен, как существующие
конвейеры для технологий X11 и DirectX. Это означало, что пользователи,
оценивающие Java приложения с использованием конвейера OGL, могли
наблюдать частые падения и различные артефакты рендеринга.
Что же было причиной падений? Если вы знакомы с OpenGL, вы возможно
знаете, наколько важно проводить весь свой рендеринг в едином потоке.
Хотя можно рендерить и из других потоков, драйверы OpenGL
оптимизированы для работы в одном потоке. В случае Java 2D
разработчикам повезло куда меньше. Запросы на рендеринг могут прийти из
любого числа потоков, включая поток обработки событий и поток
пользователя
В JDK 5.0 платформа Java справляется с этим, осуществляя подобные проверки:
* контролируя то, что лишь один поток вызывает метод OpenGL в любой момент
* используя контекст рендеринга OpenGL лишь из того потока, в котором он был создан
Благодаря этому функциональность драйверов OpenGL становится
приемлимой, но требуются значительные усилия со стороны технологии
Java, что приводит к снижению производительности. И несмотря на все
усилия, драйвера все еще могут инициировать сбой в том случае, если
приложение использует большое количество потоков для рендеринга.
Разумеется, необходимы были некие изменения в конвейере OGL, чтобы
сделать его достаточно надежным для ежедневного использования конечным
пользователем. В течение последней пары лет несколько людей из команды
Swing обсуждали идею рендеринга в едином потоке, что позволило бы
библиотекам Java взаимодействовать с локальными графическими
библиотеками, такими как OpenGL, из единого потока.
Первоначально эта идея возникла, как возможное решение множества
проблем с многопоточностью, с которыми команда Swing столкнулась в
прошлом при работе с платформой Windows. Но есть ли лучший способ
проверить эти идеи, чем их реализация в конвейере OGL? Таким образом
команда запланировала это на JDK 6. Вместо сценария на рисунке 10, в
котором множество потоков обращаются к графическому уровню системы, на
рисунке 11 представлено гораздо более элегантное решение.
Multithreaded Rendering
Рисунок 10. Многопоточный рендеринг
Single-Threaded Rendering
Рисунок 11. Рендеринг в едином потоке
Ниже представлены примерные результаты испытаний, полученные на
тестовой конфигурации Linux (JDS, 2x 2.6GHz P4, Nvidia GeForce FX
5600). В случае операционных систем Solaris и Windows, результаты
аналогичны:
*
SwingMark, внутренний эталонный тест Swing приблизительно на 15 процентов быстрее.
*
По итогам теста J2DBench, метод drawString() приблизительно на 250 процентов быстрее.
*
Методы fillRect() и drawLine(), также тестируемые в ходе J2DBench, быстрее на 2500 процентов.
*
FireStarter, внутренняя демонстрационная
программа, в состоянии отрендерить порядка 2600 спрайтов на фрэйме,
подверженных эффекту транформации, фильтрации и бленд-эффекту, при
скорости 30 фреймов в секунду - тогда как до появления STR возможности
ограничивались 1600 спрайтами.
На JDK 6 команда Swing также запланировала снизить затраты на маленькие
операции рендеринга. Имеются ввиду операции, в которых задействованы
лишь несколько пикселей - например, метод fillRect() для прямоугольника
10х10 пикселей. Уменьшение затрат в подобных случаях очень важно для
того, чтобы повысить производительность в Swing в целом, поскольку
Swing обычно работает маленькими областями в единицу времени. Например,
если вы нажимаете JButton, маленькая область наполняется цветом или
градиентом, а затем некоторое количество линий и текста отрисовывается
поверх нее. Все что способствует более быстрой работе с несколькими
пикселями, улучшает впечатление пользователя от скорости работы Swing
приложения.
Удалось достичь значительного снижения затрат благодаря исправлению следующих ошибок:
* 6255545: OGL: избежание лишних вызовов, инициирующих настройку состояния текстуры
* 6280588: OGL: избежание процедур
активации/дезактивации окружения GL_TEXTURE_2D при каждой операции,
связанной с текстурами
* 6273431: OGL: повышение производительности установки параметров в очередь
После перечисления исправлений, введенных в JDK 6, самое время
вернуться назад и представить в виде диаграммы то, что было достигнуто
командой Swing. Диаграмма представлена на рисунке 12.
OpenGL Pipeline Improvements in Java SE 6
Рисунок 12. Оптимизация конвейера OpenGL в Java SE 6
Ниже представлены big takeaways:
*
Диаграмма на рисунке 12 иллюстрирует
повышение производительности OGL Java 2D конвейера в JDK 6 (голубые
столбцы) по сравнению с OGL конвейером в JDK 5.0 (оранжевые столбцы) и
X11 конвейера, используемого по умолчанию в JDK 6 (зеленые столбцы).
*
Разумеется, это лишь небольшой
показательный пример. Сотни других операций осуществляются теперь
значительно быстрее при включенном OGL конвейере; некоторые из них
быстрее лишь на несколько процентов, нежели при использовании X11, зато
другие быстрее в 10-40 раз.
*
These performance wins are similar across all platforms: Windows, Linux, and Solaris OS.
*
Данные выигрыши в производительности
одинаково существенны для всех платформ: Windows, Linux, и Solaris ОС.
*
Поскольку данные операции ускоряются
графическим оборудованием, загрузка процессора может быть значительно
ниже при включенном конвейере OGL.
Но даже после всех этих улучшений, X11 все еще разбивает наголову
OpenGL в некоторых операциях благодаря ряду хорошо оптимизированных
циклов в Xserver - например, заполнеие маленьких овалов. Команда Swing
продолжит работу над наиболее важными моментами - тогда в идеале данная
брешь в производитедьности конвейера OGL также будет закрыта.
<Родной> стиль системы
Из записи блога " Hi-Fi Swing (Или более точное соответствие стилей системы Swing стилям операционных систем)" " Джорджа Бино
Одно из наиболее важных преимуществ Swing заключается в отсутствии
жесткой привязанности между инструментарием текущей операционной
системы и программным интерфейсом Swing. Программный интерфейс Swing
был спроектирован таким образом, чтобы иметь возможность расширяться и
не зависеть от платформы. Однако за свободу от ограничений платформы
пришлось заплатить дополнительной сложностью разработки инструментария
Swing. Разработчики Swing должны были пойти на осознаный компромисс
между точным соответствием стилю системы и независимостью от платформы.
В течении нескольких лет пользователи просили команду разработчиков
Swing обеспечить абсолютно точное соответствие пользовательских
интерфейсов стилю системы.
Возможность выбрать тему рабочего стола Windows пользуется
популярностью на протяжении нескольких лет. К примеру, произвоители
персональных компьютеров, такие как Sony или Gateway, выпускали
специально разработанные темы Windows. Благодаря им по рабочему столу
можно было идентифицировать производителя системы. К тому же многим
пользователям нравится сила и гибкость настройки рабочего стола
согласно своим предпочтениям.
Одним из наиболее популярных приложений для Windows, работающим с
темами, стал WindowBlinds. По сути WindowBlinds оказался столь
популярен, потому что Microsoft работал с автором продукта для того
чтобы разработать новый программный интерфейс, позволяющий раскрыть
детали рендеринга элементов управления Windows: программный интерфейс
UxTheme. В Windows XP по умолчанию включен новый стиль XP, основанный
на UxTheme; пользователи могут расширит его, используя программный
интерфейс UxTheme.
В JDK 5.0, команда разработчиков Swing team обеспечила поддержку стиля
Windows XP. В использованном для этого механизме читались ресурсы,
включенные в файлы стилей XP, а затем полученные иконки и цвета
использовались для рендеринга стиля Windows. К несчастью, Microsoft
изменил файлы стилей в Windows Vista таким образом, что исчезла
возможность читать из них ресурсы, используя упомянутый выше механизм
JDK 5.0. В результате, когда разработчики запускали данный JDK под
Windows Vista, их приложения обращались к классическому стилю Windows,
используемому в Windows 2000. Swing всегда обращается к этому стилю,
если не может загрузить стиль XP.
После ряда обсуждений между командой разработчиков Swing и команды
разработчиков графики Microsoft, команда Microsoft предложила способ
работы с темами Windows Vista, используя программный интерфейс UxTheme.
Далее несколько создателей стиля Swing-Windows предложили прототип
стиля Windows XP, использующего механизм UxTheme для рендеринга
компонентов Swing. Затем создатели протестировали прототип под Windows
Vista и обнаружили, что рендеринг темы Vista точен до пикселя при
использовании UxTheme. Это побудило нас заново реализовать стиль
Windows с использованием UxTheme; новая реализация доступна в JDK 6.
Взгляд вперед
Во второй части статьи обсуждается ряд других функциональных
возможностей Java SE 6, как новых, так и обновленных: сортировка и
фильтрация таблиц, оптимизация библиотеки ввода/вывода для изображений,
новая модель модальности, а также программный интерфейс рабочего стола.
Для получения более подробной информации смотрите
В целом:
*
Обновление: функциональные возможности настольной Java в Java SE 6 (январь 2006)
Заставка (Splash Screen)
*
Документация к программному интерфейсу класса SplashScreen
Панель быстрого запуска
*
Документация к программному интерфейсу классов SystemTray и TrayIcon
Стили
*
JavooToo содержит отличную подборку проектов разработки стилей.
Платформа Java
* Платформа Java Standard Edition 6 (Java SE 6)
Перевод: Шигапова К., Дмитриев А.
Оригинал |
Технологии 
