Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Отчеты bugtraq, которые соответствуют этому изменению: и
В Java 2 SDK, версия 1.2 и 1.3, общие операции на объекте Graphics часто лишали законной силы данные рендеринга, кэшируемые для этого объекта Graphics. Это аннулирование, прерванное процесс рендеринга, вызывая непрерывное воссоздание рендеринга информации для объекта Graphics, даже для таких простых и мягких операций как create(), setColor(), и translate(). Поскольку рендеринг иерархий Swing полагается в большой степени на эти общие операции, аннулирование и воссоздание рендеринга данных вызванная плохая производительность перекрашивания для многих приложений Swing.
Новая конвейерная архитектура уменьшает эти издержки производительности с несколькими изменениями реализации что:
Другие изменения в конвейерной архитектуре значительно улучшили производительность:
Аппаратное Ускорение для Внеэкранных Изображений
Отчет bugtraq, который соответствует этому изменению:
SDK 1.4 обеспечивает доступ к аппаратному ускорению для внеэкранных изображений, приводящих к лучшей производительности рендеринга к и копирования с этих изображений. Одна проблема с аппаратно ускоренными изображениями состоит в том, что, на некоторых платформах, таких как Microsoft Windows, их содержание может быть потеряно в любое время из-за обстоятельств вне управления приложения. Новый класс VolatileImage позволяет Вам создавать аппаратно ускоренное внеэкранное изображение и управлять содержанием того изображения.
Этот новый API включает:
Для получения дополнительной информации об использовании VolatileImage класс, см.
Сменная Платформа ввода-вывода Изображения
Отчет bugtraq, который соответствует этому изменению:
API ввода-вывода Изображения JavaTM является сменной, расширяемой платформой, которая поддерживает чтение и запись изображений различных форматов и протоколов. API оказывает эту поддержку через плагины, большинство которых будет записано третьими сторонами. Соответствующая реализация будет только обязана обеспечивать минимальный набор плагинов, преимущественно для совместимости с предыдущими версиями SDK Java. Приложение, используя этот API должно быть в состоянии считать и записать изображения, не зная формат хранения изображения или плагин, используемый, чтобы поддерживать формат.
Существенно, все операции ввода-вывода изображения состоят из чтения или записи потоков, которые содержат одно или более изображений, один или более предварительных просмотров (миниатюра) изображения, связанные с каждым изображением, и метаданными, которые являются всем кроме пиксельных данных.
API ввода-вывода Изображения Java позволяет приложения:
См. ввод-вывод Изображения Java для получения дополнительной информации о API ввода-вывода Изображения Java.
Отчеты bugtraq, который соответствует этому изменению:
и
Этот API является продуктом JSR006, Объединенного API Печати, и позволит клиентским приложениям обеспечивать богатый доступ к capablities служб печати, доступных включая:
Серверные приложения могут быть бенефициариями возможностей спулинга документов службам печати, тогда как ранее только графические вызовы могли использоваться, чтобы генерировать задания принтера из приложений Java.
См. Службу печати Java для получения дополнительной информации.
Поддержка плавания и двойных Типов Изображения
Отчет bugtraq, который соответствует этому изменению:
До SDK 1.4, Java 2-D API не имел подклассов DataBuffer для плавания или удваивал демонстрационные типы. API ввода-вывода Изображения Java нуждается в этих классах чтения и записи плавание и двойные типы изображения.
SDK 1.4 содержит два новых класса, чтобы оказать плавание и двойную поддержку типа изображения: DataBufferFloat и DataBufferDouble. Класс DataBufferFloat обертывает массивы плавающие пикселей. Класс DataBufferDouble обертывает двойные массивы пикселей.
Существующий ComponentColorModel и реализации класса ComponentSampleModel были также обновлены, чтобы поддерживать подписанный короткий, плавание, и двойные данные. Эти классы включают определения нормализованных диапазонов компонентных значений для недавно поддерживаемых типов данных:
Полный дополнительный API упоминается ниже.
java.awt.image.ColorModel включает три новых метода, чтобы быть параллельным существующим методам:
Отчет bugtraq, который соответствует этому изменению:
Unicode Двунаправленный Алгоритм анализирует текст, используя свойства символа Unicode и определяет направление выполнений текста. Алгоритм необходим, чтобы должным образом вывести на экран двунаправленный текст, такой как еврейский и арабский текст, в правильном порядке.
Текущая реализация все пишется в языке программирования Java, но SDK 1.4 будет включать эффективный доступ от собственного кода шрифта так, чтобы еврейский и арабский текст мог быть более эффективно представлен. SDK 1.4 обеспечит доступ к собственному коду через Java Собственный Интерфейс.
Новый общедоступный класс Bidi реализует Unicode 3.0 Алгоритма Bidi и предоставляет доступ к информации о двунаправленном переупорядочении текста так, чтобы смешанный, двунаправленный текст был должным образом выведен на экран.
Пример BidiSample демонстрирует некоторые из подпрограмм Bidi.
Шрифт Rasterizer поддерживает для вывода подсказок TrueType
Перед этим выпуском шрифт T2K rasterizer используемый 2-D Java не поддерживал вывод подсказок шрифта для шрифтов TrueType. В результате, когда шрифты TrueType не всегда выводили на экран с непротиворечивым, привлекательным появлением. Для этого выпуска T2K rasterizer был изменен, чтобы использовать подсказки, сохраненные в шрифтах TrueType.
Добавляя эту функциональность к T2K rasterizer, зависимость от собственного rasterizers была значительно уменьшена. Сокращение этой зависимости приводит к:
Шрифты Lucida, которым подсказывают,
Отчет bugtraq, который соответствует этому изменению:
Для SDK 1.4, шрифты Lucida, которые находятся в Java 2 SDK, будут обновлены, чтобы содержать подсказки. Это даст Java 2 SDK более высокие качественные шрифты, которые могли использоваться вместо существующих шрифтов или если никакие другие шрифты не доступны. Добавление подсказок к шрифтам Lucida также позволяет новому межплатформенному rasterizer подсказывать шрифты Lucida, содержавшиеся в SDK, который заставляет шрифты Lucida быть выведенными на экран более непротиворечивым и привлекательным способом.
Табличная Поддержка Шрифта OpenType
Отчет bugtraq, который соответствует этому изменению:
SDK 1.4 включает новую архитектуру для того, чтобы оказать общую поддержку шрифта OpenType. Эта новая архитектура оказывает поддержку интернационального символа для контекстных сценариев как тайский, Относящееся к Индии, арабское, и еврейский. Это также оказывает улучшенную типографскую поддержку для римских языков.
Поддержка Числового Формирования
Отчет bugtraq, который соответствует этому изменению:
В настоящий момент, когда Java 2-D цифры рендеринга, окруженные арабским текстом, у цифр есть арабские (римские) формы, которые являются обычно ожидаемыми формами цифры в большинстве стран Запада. Однако, люди в локали хинди ожидают видеть формы хинди.
Новый атрибут, TextAttribute.NUMERIC_SHAPING, и новый класс, NumericShaper, позволяет Вам сформировать цифры ASCII к другим диапазонам десятичного числа Unicode.
Например, чтобы заставить экземпляр TextLayout преобразовывать цифры из европейца на арабский язык:
Numeric Shaper nS
= NumericShaper.getContextualShaper(NumericShaper.ARABIC)
Map map = new HashMap();
map.put(TextAttribute.NUMERIC_SHAPING, nS);
FontRenderContext frc = ...;
TextLayout layout = new TextLayout(text, map, frc);
layout.draw(g2d, x, y);
Класс NumericShaper включает 19 констант, представляющих различные диапазоны десятичного числа Unicode, разрешая Вам преобразовать в 19 различных форм цифры, включая Деванагари и тайский язык.
Улучшенная Поддержка Сложного форматирования в GlyphVector
До этого выпуска клиенты не могли получить доступ к информации об отображении глифа-к-символьному от GlyphVector. Клиенты могут использовать эту информацию, чтобы узнать, которому глифы в GlyphVector соответствуют который символы. Этот выпуск также определяет новые методы, чтобы получить точные границы GlyphVector и отдельных глифов в пределах GlyphVector.
Отметьте: Хотя клиенты могут использовать GlyphVector и информацию об отображении глифа-к-символьному, чтобы реализовать выбор и поразить тестирование, большинство клиентов найдет TextLayout и Swing JTextArea и классы JTextField, чтобы быть более полезным и удобным.
Эти методы GlyphVector новы в SDK 1.4:
Shape чья внутренняя часть соответствует визуальному представлению указанного глифа в пределах этого GlyphVector, смещение к x, y.GlyphVector когда представлено в графике с данным FontRenderContext в данном расположении.GlyphVector представляется в a Graphics с данным FontRenderContext в данном расположении.Отчет bugtraq, который соответствует этому изменению:
Класс AlphaComposite обеспечивает альфа-возможности смешивания согласно режимам или правилам, установленным Швейцаром и Варёным пудингом. Из 12 правил, что Швейцар и идентифицированный Варёный пудинг, API AlphaComposite для SDK, версия 1.3 определяют и реализуют только 8 из них:
Для SDK 1.4, AlphaComposite реализует оставление 4 правилами Варёного пудинга швейцара:
Поддержка Проверки, если у Шрифта есть Преобразование
Отчет bugtraq, который соответствует этому изменению:
С SDK 1.2 у объекта Font есть атрибут преобразования, к которому можно получить доступ с методом Font.getTransform. Можно выполнить геометрические преобразования, такие как вращение и сдвиг, на Font, устанавливая атрибут преобразования. Однако, большинство приложений использует атрибут Размера, а не преобразование, чтобы управлять размером и формой символов. В этом случае преобразование является простыми идентификационными данными, преобразовывают.
В настоящий момент единственный способ определить, является ли преобразование преобразованием идентификационных данных, состоит в том, чтобы вызвать getTransform и осмотреть возвращенный AffineTransform. К сожалению, вызов getTransform требует объекта Font клонировать AffineTransform, потому что преобразование изменчиво.
Два новых метода в SDK 1.4 позволяют Вам проверять, является ли преобразование объекта Font идентификационными данными tranform, не создавая новый AffineTransform:
true если обернутое преобразование является идентификационными данными, преобразовывают.Отчет bugtraq, который соответствует этому изменению:
Объект FontRenderContext инкапсулирует состояние о графическом контексте и используется GlyphVector и TextLayout. Три новых метода в FontRenderContext позволяют Вам сравнивать FontRenderContext в GlyphVector против того в графическом контексте, в который GlyphVector тянет:
Они равняются методам, также имеют выигрыши в производительности, потому что клиент не должен создать AffineTransform, чтобы выполнить тест равенства.*As, используемые на этом веб-сайте, сроки "виртуальная машина Java" или "JVM", означают виртуальную машину для платформы Java.
