Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Новый Java 2D™ Функции в Java™ 2 SDK, v1.4


Новая Конвейерная Архитектура

Отчеты bugtraq, которые соответствуют этому изменению: 4228939 и 4268962

В Java 2 SDK, версия 1.2 и 1.3, общие операции на объекте Graphics часто лишали законной силы данные рендеринга, кэшируемые для этого объекта Graphics. Это аннулирование, прерванное процесс рендеринга, вызывая непрерывное воссоздание рендеринга информации для объекта Graphics, даже для таких простых и мягких операций как create(), setColor(), и translate(). Поскольку рендеринг иерархий Swing полагается в большой степени на эти общие операции, аннулирование и воссоздание рендеринга данных вызванная плохая производительность перекрашивания для многих приложений Swing.

Новая конвейерная архитектура уменьшает эти издержки производительности с несколькими изменениями реализации что:

Эти изменения особенно примечательны, когда следующие вызовы часто используются, как они находятся в приложениях Swing: Место времени выполнения должно также быть улучшено посредством лучшего совместного использования кода.

Другие изменения в конвейерной архитектуре значительно улучшили производительность:

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

Аппаратное ускорение для Внеэкранных Изображений

Отчет bugtraq, который соответствует этому изменению: 4330166

SDK 1.4 обеспечивает доступ к аппаратному ускорению для внеэкранных изображений, приводящих к лучшей производительности рендеринга к и копирования с этих изображений. Одна проблема с аппаратно ускоренными изображениями состоит в том, что, на некоторых платформах, таких как Microsoft Windows, их содержание может быть потеряно в любое время из-за обстоятельств вне управления приложения. Новый VolatileImage class позволяет Вам создавать аппаратно ускоренное внеэкранное изображение и управлять содержанием того изображения.

Этот новый API включает:

Для получения дополнительной информации об использовании VolatileImage class, см. Руководство пользователя API VolatileImage

Сменная Платформа ввода-вывода Изображения

Отчет bugtraq, который соответствует этому изменению: 4101949

API ввода-вывода Изображения Java™ является сменной, расширяемой платформой, которая поддерживает чтение и запись изображений различных форматов и протоколов. API оказывает эту поддержку через плагины, большинство которых будет записано третьими сторонами. Соответствующая реализация будет только обязана обеспечивать минимальный набор плагинов, преимущественно для совместимости с предыдущими версиями SDK Java. Приложение, используя этот API должно быть в состоянии считать и записать изображения, не зная формат хранения изображения или плагин, используемый, чтобы поддерживать формат.

Существенно, все операции ввода-вывода изображения состоят из чтения или записи потоков, которые содержат одно или более изображений, один или более предварительных просмотров (миниатюра) изображения, связанные с каждым изображением, и метаданными, которые являются всем кроме пиксельных данных.

API ввода-вывода Изображения Java позволяет приложения:

См. ввод-вывод Изображения Java для получения дополнительной информации о API ввода-вывода Изображения Java.

Новая Служба печати Java™

Отчеты bugtraq, который соответствует этому изменению:
4285177 и 4360752

Этот API является продуктом JSR006, Объединенного API Печати, и позволит клиентским приложениям обеспечивать богатый доступ к capablities служб печати, доступных включая:

Так как все возможности будут представлены через API, серверные приложения становятся первыми гражданами class этого API.

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

См. Службу печати Java для получения дополнительной информации.

Поддержка плавания и двойных Типов Изображения

Отчет bugtraq, который соответствует этому изменению: 4364491

До SDK 1.4, Java 2-D API не имел подклассов DataBuffer для плавания или удваивал демонстрационные типы. API ввода-вывода Изображения Java нуждается в этих классах чтения и записи плавание и двойные типы изображения.

SDK 1.4 содержит два новых класса, чтобы оказать плавание и двойную поддержку типа изображения: DataBufferFloat и DataBufferDouble. DataBufferFloat class обертывает массивы плавающие пикселей. DataBufferDouble class обертывает двойные массивы пикселей.

Существующий ComponentColorModel и ComponentSampleModel реализации class были также обновлены, чтобы поддерживать подписанный короткий, плавание, и двойные данные. Эти классы включают определения нормализованных диапазонов компонентных значений для недавно поддерживаемых типов данных:

ComponentColorModel class не будет фиксировать пиксельные данные. Приложения, как ожидают, масштабируются к соответствующему диапазону. Методы добавляются к ColorSpace class, чтобы определить на компонентный минимум и максимальные нормализованные значения. Альфа-компонентные значения должны все еще колебаться от 0.0 до 1.0 нормализованный.

Полный дополнительный API упоминается ниже.

java.awt.image.ColorModel включает три новых метода, чтобы быть параллельным существующим методам:

java.awt.image.ComponentColorModel включает нового конструктора, основанного на новых типах данных и новых методах, чтобы переопределить существующие методы ColorModel: java.awt.image.SampleModel включает два новых метода, чтобы принять новые типы данных: java.awt.image.ComponentSampleModel включает два метода, чтобы принять новые типы данных: У java.awt.image.BandedSampleModel есть три метода, которые были отредактированы, чтобы принять новые типы данных: java.awt.color.ColorSpace включает два новых метода, определяют на компонентный минимум и максимальные нормализованные значения: java.awt.color.ICC_ColorSpace включает новое переопределение методов два новых метода ColorSpace.

Общедоступный Алгоритм Bidi

Отчет bugtraq, который соответствует этому изменению: 4285083

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

Текущая реализация все пишется в языке программирования Java, но SDK 1.4 будет включать эффективный доступ от собственного кода шрифта так, чтобы еврейский и арабский текст мог быть более эффективно представлен. SDK 1.4 обеспечит доступ к собственному коду через Java Собственный Интерфейс.

Новый общедоступный Bidi class реализует Unicode 3.0 Алгоритма Bidi и предоставляет доступ к информации о двунаправленном переупорядочении текста так, чтобы смешанный, двунаправленный текст был должным образом выведен на экран.

Пример BidiSample демонстрирует некоторые из подпрограмм Bidi.

Шрифт Rasterizer поддерживает для вывода подсказок TrueType

Перед этим выпуском шрифт T2K rasterizer используемый 2-D Java не поддерживал вывод подсказок шрифта для шрифтов TrueType. В результате, когда шрифты TrueType не всегда выводили на экран с непротиворечивым, привлекательным появлением. Для этого выпуска T2K rasterizer был изменен, чтобы использовать подсказки, сохраненные в шрифтах TrueType.

Добавляя эту функциональность к T2K rasterizer, зависимость от собственного rasterizers была значительно уменьшена. Сокращение этой зависимости приводит к:

Шрифты Lucida, которым подсказывают,

Отчет bugtraq, который соответствует этому изменению: 4285089

Для SDK 1.4, шрифты Lucida, которые находятся в Java 2 SDK, будут обновлены, чтобы содержать подсказки. Это даст Java 2 SDK более высокие качественные шрифты, которые могли использоваться вместо существующих шрифтов или если никакие другие шрифты не доступны. Добавление подсказок к шрифтам Lucida также позволяет новому межплатформенному rasterizer подсказывать шрифты Lucida, содержавшиеся в SDK, который заставляет шрифты Lucida быть выведенными на экран более непротиворечивым и привлекательным способом.

Табличная Поддержка Шрифта OpenType

Отчет bugtraq, который соответствует этому изменению: 4285161

SDK 1.4 включает новую архитектуру для того, чтобы оказать общую поддержку шрифта OpenType. Эта новая архитектура оказывает поддержку интернационального символа для контекстных сценариев как тайский, Относящееся к Индии, арабское, и еврейский. Это также оказывает улучшенную типографскую поддержку для римских языков.

Поддержка Числового Формирования

Отчет bugtraq, который соответствует этому изменению: 4210199

В настоящий момент, когда 2-D Java представляет цифры, окруженные арабским текстом, у цифр есть арабские (римские) формы, которые являются обычно ожидаемыми формами цифры в большинстве стран Запада. Однако, люди в локали хинди ожидают видеть формы хинди.

Новый атрибут, TextAttribute.NUMERIC_SHAPING, и новый class, NumericShaper, позволяет Вам сформировать цифры ASCII к другим диапазонам десятичного числа Unicode.

Например, чтобы заставить экземпляр TextLayout преобразовывать цифры из европейца на арабский язык:

  1. Создайте NumericShaper, который формирует АРАБСКИЕ цифры:
          Numeric Shaper nS 
             = NumericShaper.getContextualShaper(NumericShaper.ARABIC)
    
  2. Добавьте NumericShaper к атрибуту Map наряду со значением ключа TextAttribute.NUMERIC_SHAPING:
          Map map = new HashMap();
          map.put(TextAttribute.NUMERIC_SHAPING, nS);
    
  3. Создайте TextLayout с атрибутом Map:
          FontRenderContext frc = ...;
          TextLayout layout = new TextLayout(text, map, frc);
    
  4. Представьте текст:
          layout.draw(g2d, x, y);
    

NumericShaper class включает 19 констант, представляющих различные диапазоны десятичного числа Unicode, разрешая Вам преобразовать в 19 различных форм цифры, включая Деванагари и тайский язык.

Улучшенная Поддержка Сложного форматирования в GlyphVector

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

Отметьте: Хотя клиенты могут использовать GlyphVector и информацию об отображении глифа-к-символьному, чтобы реализовать выбор и поразить тестирование, большинство клиентов найдет TextLayout и Swing JTextArea и классы JTextField, чтобы быть более полезным и удобным.

Эти методы GlyphVector новы в SDK 1.4:

Эти новые методы GlyphMetrics имеют дело с преобразованными шрифтами: Полная Поддержка Варёного пудинга швейцара

Отчет bugtraq, который соответствует этому изменению: 4380232

AlphaComposite class обеспечивает альфа-возможности смешивания согласно режимам или правилам, установленным Швейцаром и Варёным пудингом. Из 12 правил, что Швейцар и идентифицированный Варёный пудинг, API AlphaComposite для SDK, версия 1.3 определяют и реализуют только 8 из них:

Для SDK 1.4, AlphaComposite реализует оставление 4 правилами Варёного пудинга швейцара:

Поддержка Проверки, если у Шрифта есть Преобразование

Отчет bugtraq, который соответствует этому изменению: 4314043

С SDK 1.2 у объекта Font есть атрибут преобразования, к которому можно получить доступ с методом Font.getTransform. Можно выполнить геометрические преобразования, такие как вращение и сдвиг, на Font, устанавливая атрибут преобразования. Однако, большинство приложений использует атрибут Размера, а не преобразование, чтобы управлять размером и формой символов. В этом случае преобразование является простыми идентификационными данными, преобразовывают.

В настоящий момент единственный способ определить, является ли преобразование преобразованием идентификационных данных, состоит в том, чтобы вызвать getTransform и осмотреть возвращенный AffineTransform. К сожалению, вызов getTransform требует объекта Font клонировать AffineTransform, потому что преобразование изменчиво.

Два новых метода в SDK 1.4 позволяют Вам проверять, является ли преобразование объекта Font идентификационными данными tranform, не создавая новый AffineTransform:

Новые Методы Равенства для FontRenderContext

Отчет bugtraq, который соответствует этому изменению: 4328579

Объект FontRenderContext инкапсулирует состояние о графическом контексте и используется GlyphVector и TextLayout. Три новых метода в FontRenderContext позволяют Вам сравнивать FontRenderContext в GlyphVector против того в графическом контексте, в который GlyphVector тянет:

Они равняются методам, также имеют выигрыши в производительности, потому что клиент не должен создать AffineTransform, чтобы выполнить тест равенства.

*As, используемые на этом веб-сайте, сроки "виртуальная машина Java" или "JVM", означают виртуальную машину для платформы Java.


Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами