Настоящее изобретение связано со следующими совместно рассматриваемыми заявками на патент США: 10/184,795, под названием «Система и способ многоуровневой обработки графики» [Multi-Level Graphics Processing system and Method], 10/184,796 под названием «Родовая параметризация для графа сцены» [Generic Parameterization for Scene Graph], 10/185,775 под названием «Интеллектуальная структура данных кэширования для графики прямого режима» [Intelligent Caching Data Structure for Immediate Mode Graphics], поданные 27 июня 2002г., и заявкой на патент США под названием «Интерфейсы визуалов и графов сцены» [Visual and Scene Graph Interfaces], (зарегистрирована у поверенного под №3470), поданной одновременно с ними. Права каждой связанной заявки принадлежат заявителю настоящей патентной заявки.
Область изобретения
Изобретение относится, в целом, к компьютерным системам и, в частности, к обработке графической и иной видеоинформации для отображения в компьютерных системах.
Предшествующий уровень техники
Традиционная модель прямого режима доступа к графике в компьютерных системах исчерпала свои возможности отчасти потому, что скорости памяти и шины отстают от усовершенствований в главных процессорах и/или графических процессорах. В целом, современная модель (например, WM_PAINT) для подготовки кадра требует обработки столь больших объемов данных, что частота регенерации оборудования оказывается недостаточной, когда требуются сложные графические эффекты. В результате, при попытках создать сложные графические эффекты с помощью традиционных графических моделей, вместо завершения изменений, которые приводят к ожидаемым визуальным эффектам в следующем кадре, изменения могут добавляться в разные кадры, приводя к нежелательным визуально-наблюдаемым результатам.
В вышеупомянутых заявках на патент США №№ 10/184,795, 10/184,796 и 10/185,775 описана новая модель для управления выводом графики. Эта новая модель обеспечивает ряд значительных усовершенствований в технологии обработки графики. Например, заявка США № 10/184,795, в основном, посвящена системе и способу многоуровневой обработки графики, в которой компонент более высокого уровня (например, операционной системы) берет на себя большой объем вычислений для построения графа сцены, обновления параметров анимации и обхода структур данных графа сцены, при относительно низкой скорости операций, передавая низкоуровневому компоненту упрощенные структуры данных и/или команды графики. Поскольку высокоуровневая обработка значительно упрощает данные, низкоуровневый компонент может работать на более высокой скорости (относительно высокоуровневого компонента), например, на скорости, которая соответствует частоте обновления кадров графической подсистемы, преобразуя данные в постоянные выходные данные для графической подсистемы. При использовании анимации низкоуровневая обработка позволяет вместо повторного рисования всей сцены с изменениями интерполировать интервалы параметров по мере необходимости, чтобы получать мгновенные значения, которые при визуализации обеспечивают слегка измененную сцену для каждого кадра, обеспечивая плавную анимацию.
В заявке США № 10/184,796 описан параметризованный граф сцены, который обеспечивает изменяемые (анимационные) значения и контейнеры параметризованного графа, благодаря которым программный код, предусматривающий вырисовывание графики (например, прикладная программа или компонент операционной системы), может избирательно изменять определенные аспекты описания графа сцены, оставляя другие аспекты без изменений. Программный код также может повторно использовать построенные ранее участки графа сцены, возможно, с другими параметрами. Очевидно, что возможность легко изменять внешний вид отображаемых предметов посредством параметризации и/или повторного использования существующих частей графа сцены обеспечивает существенное повышение общей эффективности обработки графики.
В заявке США № 10/185,775 в общем виде описаны структура данных кэширования и соответствующие механизмы сохранения визуальной информации посредством объектов и данных в графе сцены. Структура данных в целом связана с механизмами, которые интеллектуально управляют заполнением его визуальной информацией и ее использованием. Например, в отсутствие конкретных требований со стороны прикладной программы, большая часть информации, хранящейся в структуре данных, не имеет внешних ссылок на нее, что позволяет оптимизировать или иначе обрабатывать эту информацию. Очевидно, это обеспечивает эффективность и экономию ресурсов, например, данные в структуре данных кэша можно преобразовывать в другой формат, который является более компактным и/или уменьшает потребность в последующей повторной обработке, например растровый формат изображения или другой результат последующей обработки.
Хотя вышеупомянутые усовершенствования и обеспечивают существенные преимущества в технологии обработки графики, тем не менее необходим способ, позволяющий программам эффективно и просто использовать эту усовершенствованную модель графики и ее другие связанные с ней усовершенствования. Необходим универсальный и в то же время простой способ, позволяющий программам пользоваться многочисленными особенностями и возможностями обработки графики, предусмотренными усовершенствованной моделью графики, и, таким образом, эффективно выводить сложную графику.
Сущность изобретения
В принципе, настоящее изобретение предусматривает объектную модель элементов и язык разметки векторной графики для осуществления доступа к этой объектной модели элементов таким образом, чтобы разработчики программных кодов могли согласованно взаимодействовать со структурой данных графа сцены для создания графики. Язык разметки для векторной графики содержит формат взаимного обмена для выражения векторной графики через объектную модель элементов. При интерпретации разметка анализируется в данные, включающие в себя элементы в элементном дереве, которое транслируется в объекты структуры данных графа сцены. На уровне элементного дерева предусмотрены система свойств и система презентаторов, обеспечивающие широкие возможности программирования, в том числе характеристики наследования и обработку событий, облегчающие конструкторам сцен работу по конструированию, возможно, сложных сцен. В общем случае элементы векторной графики соответствуют элементам «форма» и другим элементам, в том числе элементам «изображение» и «видео», которые коррелируют с объектами графа сцены в объектной модели графа сцены. Свойства и другие ресурсы элементов векторной графики также коррелируют с аналогичными свойствами и ресурсами объектной модели графа сцены.
Таким образом, система векторной графики может программировать на уровне элементов, на котором каждая форма рисования представлена как элемент на том же уровне, что и остальные программируемые элементы в странице/экране, что позволяет взаимодействовать с системой презентаторов, событиями и свойствами. Система векторной графики также обеспечивает механизм программирования на уровне ресурсов, благодаря которому конструкторы сцен могут существенно урезать элементное дерево и систему презентаторов и программировать непосредственно на уровне API визуалов, который взаимодействует со структурой данных графа сцены. Это обеспечивает более эффективный и простой способ вывода соответствующего объекта, хотя и с частичной потерей программируемости на уровне элементов. В одной реализации при программировании заливки типа «кисть визуала» анализатор может напрямую вызывать уровень API с помощью данных уровня ресурсов для создания соответствующего объекта раскраски визуала (что также является корреляцией между объектной моделью элементов и объектной моделью графа сцены). В этой двухуровневой системе векторная графика уровня элементов анализируется (осуществляется разбор) в созданные элементы, которые подлежат дальнейшей трансляции в объекты, тогда как векторная графика уровня ресурсов анализируется и непосредственно сохраняется эффективным способом. В то же время элементы и часть элементного дерева могут ссылаться на созданные таким образом данные или объекты уровня ресурсов. Для этого элементы, в том числе элементы раскраски визуала, можно снабжать именами. Таким образом, конструктор сцены имеет возможность балансировать между эффективностью и программируемостью по мере необходимости.
Иерархия классов элементов включает в себя класс формы, класс изображения, класс видео и класс холста. Элементы класса формы включают в себя прямоугольник, полилинию, многоугольник, путь, линию и эллипс. Каждый элемент может включать в себя данные (свойства) заливки, данные обводки, данные отсечения, данные трансформации, данные эффекта фильтра и данные маски или быть связан с ними. Формы соответствуют геометрии (объектной модели графа сцены), рисуемой с унаследованными и каскадированными свойствами презентации, которые используются для построения пера и кисти, необходимых для рисования форм. Класс «изображение» является более специфичным, чем «форма», и может включать в себя больше растровых графических данных, а класс «видео» позволяет воспроизводить видео (или аналогичные мультимедиа) в отображаемом элементе. Класс «холста» может действовать как контейнер для форм, чтобы обеспечивать облегченность форм.
В одном варианте реализации код разметки интерпретируется анализатором/транслятором, который, в общем случае, добавляет элементы из уровня элементов к системе элементного дерева/свойств и присоединяет к этим элементам презентаторы. Затем система презентаторов берет элементное дерево с присоединенными презентаторами и транслирует данные в объекты (с помощью построителя) и обращается к уровню API визуалов, который взаимодействует с графом сцены и создает объекты графа сцены.
Язык разметки обеспечивает различные способы описания элемента, включая формат простой строки и сложную систему записи объекта (сложный синтаксис свойств). Применительно к формату простой строки анализатор/транслятор и/или система презентаторов использует преобразователь типов для преобразования строки в соответствующий объект API визуалов. Когда атрибут заливки слишком сложен, чтобы уместиться в одной строке, для описания набора свойств используется сложный синтаксис свойств, который может быть встроен в разметку. Поскольку уровень элементов и уровень API совместно используют одну и ту же модель визуализации, многие объекты являются одинаковыми, что обеспечивает высокую эффективность анализа/трансляции и другие преимущества. Экземпляр ресурса может также размещаться в другом месте (например, в разметке или файле) и допускает ссылку по имени. Таким образом, конструктор сцен может повторно использовать элемент элементного дерева в пределах сцены, в том числе элементы, описанные сложным синтаксисом свойств. Другие преимущества и достоинства явствуют из нижеследующего подробного описания, приведенного в сочетании с чертежами.
Краткое описание чертежей
Фиг.1 - блок-схема иллюстративной компьютерной системы, пригодной для реализации настоящего изобретения.
Фиг.2 - обобщенная блок-схема многоуровневой архитектуры графики, пригодной для реализации настоящего изобретения.
Фиг.3 - представление графа сцены, состоящего из визуалов и связанных с ними компонентов для обработки графа сцены, например, путем обхода графа сцены для обеспечения команд графики и других данных, в соответствии с аспектом настоящего изобретения.
Фиг.4 - представление графа сцены, состоящего из визуалов удостоверения, визуалов рисования и связанных с ними примитивов рисования, созданного в соответствии с аспектом настоящего изобретения.
Фиг.5 - представление класса визуалов объектной модели в соответствии с аспектом настоящего изобретения.
Фиг.6 - представление различных других объектов объектной модели в соответствии с аспектом настоящего изобретения.
Фиг.7 - диаграмма трансформации данных визуала в соответствии с аспектом настоящего изобретения.
Фиг. 8А и 8В - представления трансформаций данных визуала в геометрическом масштабе и неоднородном масштабе соответственно, в соответствии с аспектом настоящего изобретения.
Фиг. 9А-9С - блок-схемы объектов «визуал поверхности» и других визуалов и компонентов в соответствии с аспектом настоящего изобретения.
Фиг. 10А и 10В - диаграммы, представляющие объекты «визуал HWnd» в соответствии с аспектом настоящего изобретения.
Фиг.11 - диаграмма многослойного объекта «визуал» в соответствии с аспектом настоящего изобретения.
Фиг.12 - представление классов геометрии объектной модели в соответствии с аспектом настоящего изобретения.
Фиг.13 - представление структуры PathGeometry («геометрия пути») в соответствии с аспектом настоящего изобретения.
Фиг.14 - представление графа сцены, состоящего из визуалов и примитивов рисования, где показана иллюстративная графика, созданная примитивами, в соответствии с аспектом настоящего изобретения.
Фиг.15 - представление классов кисти объектной модели в соответствии с аспектом настоящего изобретения.
Фиг.16 - представление визуализированной графики, полученной из данных в объекте «кисть с линейным градиентом», в соответствии с аспектом настоящего изобретения.
Фиг.17 - представление визуализированной графики, полученной из данных в объекте «кисть с радиальным градиентом», в соответствии с аспектом настоящего изобретения.
Фиг.18 - представление визуализированной графики, полученной при различных значениях растяжения, в соответствии с аспектом настоящего изобретения.
Фиг.19 - представление визуализированной графики, получающейся в результате наличия различных значений элемента мозаичного изображения, в соответствии с аспектом настоящего изобретения.
Фиг.20 - последовательность операций, представляющая, в общем виде, логику для интерпретации визуала, в том числе объекта «кисть», позволяющую генерировать графику, в соответствии с аспектом настоящего изобретения.
Фиг.21 - представление сетки и трансформированной сетки, полученной из данных в объекте «кисть визуала», в соответствии с аспектом настоящего изобретения.
Фиг.22 - представление сетки и трансформированной сетки, визуализированная графика в которой нарисована из визуала, в соответствии с аспектом настоящего изобретения.
Фиг.23 - представление визуализированного объекта «кисть с девятиячеечной сеткой» в соответствии с аспектом настоящего изобретения.
Фиг.24 - представление классов трансформации объектной модели в соответствии с аспектом настоящего изобретения.
Фиг.25 - представление классов элемента в объектной модели элементов в соответствии с аспектом настоящего изобретения.
Фиг.26 - представление компонентов для интерпретации кода языка разметки для взаимодействия с уровнем API визуалов в соответствии с аспектом настоящего изобретения.
Фиг.27 - представление отсечения посредством пути геометрии в соответствии с аспектом настоящего изобретения.
Подробное описание
Иллюстративная операционная среда
На фиг.1 показан пример компьютерной среды 100, подходящей для реализации изобретения. Среда 100 вычислительной системы является только одним примером подходящей вычислительной среды и не накладывает никаких ограничений на объем использования или функции изобретения. Кроме того, вычислительную среду 100 не следует интерпретировать как имеющую какую-либо зависимость или необходимость, относящуюся к одному или комбинации компонентов, указанных в иллюстративной операционной среде 100.
Изобретение предусматривает многочисленные другие среды или конфигурации вычислительных систем общего назначения и специального назначения. Примеры общеизвестных вычислительных систем, сред и/или конфигураций, которые могут быть пригодны для реализации настоящего изобретения, включают в себя, но не исключительно, персональные компьютеры, компьютеры-серверы, карманные или портативные устройства, планшетные устройства, многопроцессорные системы, системы на базе микропроцессора, приставки, программируемую бытовую электронику, сетевые ПК, мини-компьютеры, главные компьютеры, распределенные вычислительные среды, включающие в себя любые из вышеперечисленных систем или устройств, и т.п.
Изобретение можно описывать в общем контексте выполняемых на компьютере инструкций, например программных модулей, выполняемых компьютером. В целом, программные модули включают в себя процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют определенные абстрактные типы данных. Изобретение можно также осуществлять на практике в распределенных вычислительных средах, где задания выполняются удаленными обрабатывающими устройствами, подключенными посредством сети связи. В распределенной компьютерной среде, программные модули могут размещаться как на локальных, так и на удаленных компьютерных носителях информации, включая запоминающие устройства.
Согласно фиг.1 иллюстративная система, реализующая настоящее изобретение, включает в себя вычислительное устройство общего назначения в виде компьютера 110. Компоненты компьютера 110 могут включать в себя, но не только, процессор 120, системную память 130 и системную шину 121, которая подключает различные компоненты системы, в том числе системную память, к процессору 120. Системная шина 121 может относиться к любому из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующих любую из разнообразных шинных архитектур. В порядке примера, но не ограничения, такие архитектуры включают в себя шину, соответствующую промышленному стандарту архитектуры (ISA), шину, соответствующую стандарту микроканальной архитектуры (МСА), шину, соответствующую расширенному ISA (EISA), локальную шину, соответствующую стандарту Ассоциации по стандартам в области видеоэлектроники (VESA), и шину, соответствующую стандарту подключения периферийных компонентов (PCI) (именуемую также шиной расширения).
Компьютер 110 обычно включает в себя разнообразные компьютерно-считываемые носители. Считываемые компьютером носители могут представлять собой любые имеющиеся носители, к которым может обращаться компьютер 110, в том числе энергозависимые и энергонезависимые носители, сменные и стационарные носители. В порядке примера, но не ограничения, считываемые компьютером носители могут включать в себя компьютерные носители для хранения данных и среды передачи данных. Компьютерные носители для хранения данных включают в себя энергозависимые и энергонезависимые, сменные и стационарные носители, реализованные посредством любого метода или технологии хранения информации, например считываемых компьютером команд, структур данных, программных модулей или иных данных. Компьютерные носители для хранения данных включают в себя, помимо прочего, ОЗУ, ПЗУ, ЭППЗУ, флэш-память и другие запоминающие устройства, CD-ROM, цифровые универсальные диски (DVD) или иной оптический дисковый носитель данных, магнитные кассеты, магнитную ленту, магнитный дисковый носитель данных, или иные магнитные запоминающие устройства, или любой иной носитель, который можно использовать для хранения полезной информации и к которому может обращаться компьютер 110. Среды передачи данных обычно реализуют считываемые компьютером команды, структуры данных, программные модули или иные данные в виде сигнала, модулируемого данными, например, несущей волны или иного транспортного механизма, и включают в себя любые среды доставки информации. Термин «сигнал, модулируемый данными» означает сигнал, одну или несколько характеристик которого задают или изменяют определенным образом, кодируя в нем информацию. Среды передачи данных могут, например, помимо прочего, включать в себя проводные среды, например проводную сеть или прямое проводное соединение, и беспроводные среды, например акустические, РЧ (радиочастотные), инфракрасные и другие беспроводные среды. Понятие компьютерно-считываемого носителя охватывает также любые комбинации вышеперечисленных носителей.
Системная память 130 включает в себя компьютерные носители для хранения данных в виде энергозависимой и энергонезависимой памяти, например постоянного запоминающего устройства (ПЗУ) 131 и оперативного запоминающего устройства (ОЗУ) 132. Базовая система ввода/вывода (BIOS) 133, содержащая базовые процедуры, обеспечивающие перенос информации между элементами компьютера 110, например, при запуске, обычно хранится в ПЗУ 131. В ОЗУ 132 обычно хранятся данные и программные модули, подлежащие быстрому доступу со стороны процессора 120, или обрабатываемые им в данный момент. В порядке примера, но не ограничения, на фиг.1 показаны операционная система 134, прикладные программы 136, другие программные модули 137 и программные данные 138.
Компьютер 110 может также содержать другие сменные/стационарные, энергозависимые/энергонезависимые компьютерные носители для хранения данных. Исключительно в порядке примера, на фиг.1 показан жесткий диск 141, который позволяет считывать информацию со стационарного энергонезависимого магнитного носителя и записывать информацию на него, дисковод 151 для дискет, который считывает информацию со сменного энергонезависимого магнитного диска 152 или записывает информацию на него, и дисковод 155 для оптических дисков, который считывает информацию со сменного энергонезависимого оптического диска 156, например CD-ROM или иного оптического носителя, или записывает информацию на него. В иллюстративной операционной среде можно также использовать другие сменные/стационарные, энергозависимые/энергонезависимые компьютерные носители для хранения данных, например кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, ленту для цифровой видеозаписи, полупроводниковое ОЗУ, полупроводниковое ПЗУ и т.д. Жесткий диск 141, как правило, подключен к системной шине 121 через интерфейс запоминающего устройства со стационарным носителем, например интерфейс 140, а дисковод 151 для дискет и дисковод 155 для оптических дисков, как правило, подключен к системной шине 121 через интерфейс запоминающего устройства со сменным носителем, например интерфейс 150.
Вышеупомянутые и изображенные на фиг.1 приводы и соответствующие компьютерные носители для хранения данных обеспечивают хранение компьютерно-считываемых команд, структур данных, программных модулей и других данных для компьютера 110. Например, согласно фиг.1 на жестком диске 141 хранится операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147. Заметим, что эти компоненты могут быть идентичны операционной системе 134, прикладным программам 135, другим программным модулям 137 и программным данным 138 или отличны от них. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 обозначены другими позициями, поскольку они, как минимум, могут представлять собой разные копии. Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, например клавиатуру 162 и указательное устройство 161, в качестве которого может выступать мышь, шаровой манипулятор или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровой пульт, спутниковую тарелку, сканнер и т.д. Эти и другие устройства ввода обычно подключаются к процессору 120 через интерфейс 160 пользовательского ввода, подключенный к системной шине 121, но могут подключаться посредством других интерфейсов и шинных структур, например параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 191 или устройство отображения другого типа также подключено к системной шине 121 посредством интерфейса, например видеоинтерфейса 190. Монитор 191 также может быть объединен с сенсорной панелью 193 или подобным устройством, способным вводить оцифрованный входной сигнал, например рукописный текст, в компьютерную систему 110 через интерфейс, например интерфейс 192 сенсорного экрана. Заметим, что монитор и/или сенсорная панель могут быть физически соединены с корпусом, в котором размещается вычислительное устройство 110, например в персональном компьютере планшетного типа, где сенсорная панель 193, по существу, играет роль планшета 164. Кроме того, компьютеры, в частности вычислительное устройство 110, могут также содержать другие периферийные устройства вывода, например громкоговорители 197 или принтер 196, которые могут подключаться через интерфейс 195 периферийных устройств вывода.
Компьютер 110 может работать в сетевой или распределенной среде, используя логические линии связи с одним или несколькими удаленными компьютерами, например удаленным компьютером 180. Удаленный компьютер 180 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой ПК, равноправное устройство или другой общий узел сети и обычно содержит многие или все элементы, описанные выше в отношении компьютера 110, хотя на фиг.1 изображено только запоминающее устройство 181. Логические линии связи, обозначенные на фиг.1, включают в себя локальную вычислительную сеть (ЛС) 171 и глобальную сеть (ГС) 173, а также, возможно, и другие сети/шины. Такие сетевые среды широко распространены в жилых домах, учреждениях, учрежденческих компьютерных сетях, интранетах и в Интернете.
При использовании в сетевой среде ЛС компьютер 110 подключают к ЛС 171 посредством сетевого интерфейса или адаптера 170. При использовании в сетевой среде ГС компьютер 110 обычно содержит модем 172 или другое средство установления связи через ГС 173, например Интернет. Модем 172, который может быть внутренним или внешним, можно подключать к системной шине 121 через интерфейс 160 пользовательского ввода или посредством другого подходящего механизма. В сетевой среде программные модули, указанные применительно к компьютеру 110, или их фрагменты могут храниться в удаленном запоминающем устройстве. В порядке примера, но не в целях ограничения, на фиг.1 показано, что удаленные прикладные программы 185 хранятся в запоминающем устройстве 181. Очевидно, что, помимо сетевых линий связи, показанных в качестве примера, для установления линии связи между компьютерами можно использовать другие средства.
Архитектура графики
Согласно одному аспекту настоящего изобретения программный код, например приложение или компонент операционной системы, передает команды рисования и другую информацию (например, растровые изображения) графическим компонентам с целью визуализации графического выхода на системном дисплее. Для этого настоящее изобретение предусматривает язык разметки совместно с рядом элементов «форма» и других элементов, систему группирования и наложения и объединение с системой общих свойств в объектной модели, чтобы программы могли заполнять граф сцены структурами данных, примитивами (командами) рисования и другими данными, относящимися к графике. В результате обработки графа сцены получают графику (графическим изображениям), отображаемую на экране.
На фиг.2 в общем виде представлена многоуровневая архитектура 200, пригодная для реализации настоящего изобретения. Согласно фиг.2 можно разработать программный код 202 (например, прикладную программу или компонент операционной системы и пр.), позволяющий выводить графические данные одним или несколькими разными способами, в том числе посредством построения изображения 204, посредством элементов векторной графики 206 и/или посредством вызовов функции/метода, размещенной/ого непосредственно на уровне 212 программного интерфейса приложения (API) визуалов. Непосредственное взаимодействие с уровнем API дополнительно описано в вышеупомянутой совместно рассматриваемой патентной заявке под названием «Интерфейсы визуалов и графов сцены».
В общем случае построение изображения 204 обеспечивает программный код 202 механизмом загрузки, редактирования и сохранения изображений, например растровых изображений. Эти изображения могут быть использованы другими частями системы, и также имеется способ использования кода рисования примитива для непосредственного рисования изображения.
Согласно аспекту настоящего изобретения элементы векторной графики 206 обеспечивают другой способ рисования графики, согласованный с остатком объектной модели (описанный ниже). Элементы векторной графики 206 можно создавать с помощью языка разметки, который система 208 элементов/свойств и система 210 презентаторов обрабатывают, чтобы осуществить надлежащие вызовы уровню 212 API визуалов. Как описано ниже со ссылкой на фиг.26, в целом элементы 206 векторной графики анализируются в объекты объектной модели, из которой происходит рисование графа сцены, которые могут быть предоставлены графу сцены посредством уровня элементов с помощью системы 208 элементов/свойств и системы 210 презентаторов, или могут обеспечиваться более эффективным способом на уровне ресурсов, что также описано ниже.
В одном варианте реализации архитектура 200 уровня графики включает в себя высокоуровневую машину 214 наложения и анимации, которая включает в себя структуру данных 216 кэширования или иначе связана с ней. Структура данных 216 кэширования содержит граф сцены, содержащий иерархически-организованные объекты, управляемые согласно заданной объектной модели, описанной ниже. В целом, уровень 212 API визуалов обеспечивает программный код 202 (и систему 210 презентаторов) интерфейсом к структуре данных 216 кэширования, включающим в себя способность создавать объекты, открывать и закрывать объекты для передачи им данных и т.д. Другими словами, высокоуровневая машина 214 наложения и анимации предоставляет уровень 212 API унифицированных сред, с помощью которого разработчики могут выражать намерения в отношении графики и сред, чтобы отображать графическую информацию и обеспечивать нижележащую платформу достаточной информацией, чтобы платформа могла оптимизировать использование оборудования для программного кода. Например, нижележащая платформа будет отвечать за кэширование, согласование ресурсов и интеграцию сред.
В одном варианте реализации высокоуровневая машина 214 наложения и анимации передает поток команд и, возможно, другие данные (например, указатели на растровые изображения) быстрой, низкоуровневой машине 218 наложения и анимации. Используемые здесь термины «высокоуровневый» и «низкоуровневый» аналогичны тем, что используются в других вычислительных сценариях, где, в целом, чем ниже программный компонент относительно более высоких компонентов, тем ближе этот компонент к оборудованию. Так, например, графическая информация, отправленная с высокоуровневой машины 214 наложения и анимации, может быть принята на низкоуровневой машине 218 наложения и анимации, где информация используется для отправки графических данных на графическую подсистему 222, содержащую оборудование.
Высокоуровневая машина 214 наложения и анимации, совместно с программным кодом 202, строит граф сцены для представления сцены графики, обеспечиваемой программным кодом 202. Например, каждый предмет, подлежащий рисованию, можно загружать с помощью программ рисования, которые система может кэшировать в структуре данных 216 графа сцены. Как будет описано ниже, имеется несколько разных способов задавать эту структуру данных 216 и что рисовать. Далее, высокоуровневая машина 214 наложения и анимации объединяется с системами 220 хронирования и анимации для обеспечения декларативного (или другого) управления анимацией (например, интервалов анимации) и управления хронированием. Заметим, что система анимации позволяет передавать анимационные значения практически повсюду в системе, в том числе, например, на уровне 208 элемента/свойства, внутри уровня 212 API визуалов и в любых других ресурсах. Система хронирования представляется на уровнях элементов и визуалов.
Низкоуровневая машина 218 наложения и анимации управляет наложением, анимацией и визуализацией сцены, которая затем поступает на графическую подсистему 222. Низкоуровневая машина 218 компонует визуализации для сцен нескольких приложений и с помощью компонентов визуализации реализует фактическую визуализацию графики на экране. Заметим, однако, что временами может быть необходимо и/или выгодно осуществлять ту или иную визуализацию на более высоких уровнях. Например, хотя более низкие уровни обслуживают запросы от нескольких приложений, более высокие уровни обрабатываются на основе приложений, что позволяет посредством механизмов 204 построения изображения осуществлять времясберегающую или специализированную по приложениям визуализацию на более высоких уровнях и передавать ссылки на растровое изображение более низким уровням.
Объектная модель графа сцены
Согласно описанному ниже модель визуализации совместно используется высокоуровневыми, управляемыми элементами 206 векторной графики и низкоуровневыми объектами, созданными посредством уровня 212 API визуала, используемыми в структуре 216 данных графа сцены. Это обеспечивает значительную степень корреляции между высокоуровневыми элементами согласно настоящему изобретению и низкоуровневыми объектами. Ниже описана одна реализация объектной модели графа сцены.
На фиг. 3 и 4 показаны иллюстративные графы сцены 300 и 400 соответственно, базовый объект которых называется визуалом. В целом, визуал представляет собой объект, представляющий пользователю виртуальную поверхность и имеющий визуальное представление на экране дисплея. Согласно фиг.5 визуал базового класса обеспечивает базовые функции для визуалов других типов, т.е. класс 500 визуалов является абстрактным базовым классом, порождающим типы визуалов (например, 501-506).
Согласно фиг.3 визуал 302 верхнего уровня (корневой визуал) связан с объектом 304 «менеджер визуалов», который также имеет связь (например, посредством описателя) с окном 306 (HWnd) или аналогичным модулем, в котором графические данные выводятся для программного кода. Менеджер 304 визуалов управляет рисованием визуала верхнего уровня (и любых потомков этого визуала) в этом окне 306. На фиг.6 менеджер визуалов показан как один из ряда других объектов 620 в объектной модели описанной здесь графической системы.
Для рисования менеджер 304 визуалов обрабатывает (например, обходит или передает) граф сцены согласно расписанию, заданному диспетчером 308, и передает команды графики и другие данные низкоуровневому компоненту 218 (фиг.2) для его соответствующего окна 306, что в общих чертах описано в патентных заявках США №№ 10/184,795, 10/184,796 и 10/185,775. Обработка графа сцены обычно планируется диспетчером 308 на частоте, более низкой по сравнению с частотой обновления низкоуровневого компонента 218 и/или графической подсистемы 222. На фиг.3 показано несколько дочерних визуалов 310-315, организованных в иерархическом порядке под визуалом 302 верхнего уровня (корневым визуалом), некоторые из которых представлены как заполненные контекстами рисования 316, 317 (показанными в виде пунктирных прямоугольников, что выражает их временный характер) и связанные со списками 318 и 319 команд соответственно, содержащими, например, примитивы рисования и другие визуалы. Визуалы также могут содержать другую информацию свойств, что показано в нижеследующем иллюстративном классе визуалов:
Трансформация (преобразование), установленная свойством «трансформация», задает систему координат для подграфа визуала. Система координат до трансформации называется предтрансформационной системой координат, а после трансформации - посттрансформационной системой координат, т.е. визуал с трансформацией эквивалентен визуалу, имеющему узел трансформации в качестве родителя. На фиг.7 в общем виде представлен пример трансформации, идентифицирующий предтрансформационную и посттрансформационную системы координат по отношению к визуалу. Чтобы получить или установить трансформацию визуала, можно использовать свойство «трансформация» (Transform).
Заметим, что трансформации координат можно применять унифицированным способом ко всему, как в растровом изображении. Заметим, что это не означает, что трансформации всегда применяются к растровым изображениям, но на то, что визуализируется, трансформации влияют одинаково. Например, если пользователь рисует круг круглым пером шириной один дюйм и затем применяет масштабирование в направлении Х с коэффициентом два, то перо будет иметь ширину два дюйма слева направо и только один дюйм сверху вниз. Это иногда называют наложением или трансформацией растрового изображения (в отличие от скелетного или геометрического масштабирования, которое влияет только на геометрию). На фиг.8А представлена трансформация масштабирования, причем нетрансформированное изображение 800 показано слева, а трансформированное изображение 802 с неоднородным масштабированием показано справа. На фиг.8В представлена трансформация масштабирования, причем нетрансформированное изображение 800 показано слева, а трансформированное изображение 804 с геометрическим масштабированием показано справа.
В отношении координатной трансформации визуала, TransformToDescendant трансформирует точку из исходного визуала в дочерний визуал. Точка трансформируется из посттрансформационного координатного пространства исходного визуала в посттрансформационное координатное пространство дочернего визуала. TransformFromDescendant трансформирует точку из дочернего визуала вверх по родительской цепи в исходный визуал. Точка трансформируется из посттрансформационного координатного пространства дочернего визуала в посттрансформационное координатное пространство исходного визуала. Метод CalculateBounds возвращает прямоугольник границ содержимого визуала из посттрансформационного координатного пространства. Заметим, что может существовать альтернативная версия API, где допустимы более конкретные указания, например, как трансформация на визуале интерпретируется в ходе координатной трансформации. Например, можно учитывать или не учитывать трансформацию на исходном и дочернем визуале. Таким образом, эта альтернатива предусматривает четыре опции, например, координаты можно трансформировать из предтрансформационного пространства в предтрансформационное пространство, из предтрансформационного пространства в посттрансформационное пространство, из посттрансформационного пространства в предтрансформационное пространство и из посттрансформационного пространства в посттрансформационное пространство. Та же идея применяется к тестированию выбора, например, тестирование выбора может начинаться в предтрансформационном или посттрансформационном координатном пространстве, и результаты тестирования выбора могут быть в предтрансформационном или посттрансформационном координатном пространстве.
Свойство «отсечение» устанавливает (и получает) область отсечения визуала. В качестве области отсечения можно использовать любую «геометрию» (Geometry) (класс геометрии описан ниже со ссылкой на фиг.12), и область отсечения применяется в посттрансформационном координатном пространстве. В одной реализации установка по умолчанию для области отсечения равна null, т.е. отсечение отсутствует, что можно рассматривать как бесконечно большой прямоугольник отсечения от (-∞,-∞) до (+∞,+∞).
Свойство «непрозрачность» (Opacity) получает/устанавливает значение непрозрачности визуала, так что контент визуала смешивается на поверхности рисования в зависимости от значения непрозрачности и выбранного режима смешивания. Свойство «режим смешивания» (BlendMode) можно использовать для установления (или получения) используемого режима смешивания. Например, значение непрозрачности (альфа) можно задавать в пределах от 0.0 до 1.0, выбирая линейный относительно альфа режим смешивания, например Цвет = альфа * цвет изображения + (1.0 - альфа) * цвет фона). В визуал могут быть включены другие услуги, например свойства спецэффектов, например размывание, черно-белое изображение и т.д.
Различные услуги (включая трансформацию, непрозрачность, отсечение) можно помещать и извлекать на контексте рисования, и операции помещения/извлечения могут быть вложенными, если только вызов извлечения сочетается с вызовом помещения. Например, последовательность операций PushTransform(...); PushOpacity(...); PopTransform(...) является незаконной, поскольку прежде, чем вызывать PopTransform, нужно вызвать PopOpacity.
Метод PushTransform помещает (устанавливает, задает) трансформацию. Последующие операции рисования выполняются в отношении заданной трансформации. PopTransform извлекает трансформацию, заданную сочетающимся вызовом PushTransform:
void PushTransform(Transform transform);
void PushTransform(Matrix matrix);
void PopTransform().
Аналогично, метод PushOpacity помещает (задает) значение непрозрачности. Последующие операции рисования визуализируются на временной поверхности с заданным значением непрозрачности, после чего компонуются в сцену. PopOpacity извлекает непрозрачность, помещенную сочетающимся вызовом PushOpacity:
void PushOpacity(float opacity);
void PushOpacity(NumberAnimationBase opacity);
void PopOpacity().
Метод PushClip задает геометрию отсечения. Последующие операции рисования отсекаются до геометрии. Отсечение применяется в посттрансформационном пространстве. PopClip извлекает область отсечения, помещенную сочетающимся вызовом PushClip:
void PushClip(Geometry clip);
void PopClip().
Заметим, что операции помещения могут быть вложенными на любую глубину, если только операции извлечения сочетаются с помещением. Например, допустима следующая последовательность операций:
Тестирование выбора осуществляется в посттрансформационном координатном пространстве и возвращает идентификатор каждого визуала, тестируемого по выбору, который выбирают, например, путем регистрации щелчка пера или мыши. Альтернативная версия интерфейса допускает, чтобы тестирование выбора начиналось в предтрансформационном координатном пространстве относительно визуала, где начинается тестирования выбора. Выбираемые визуалы возвращаются в порядке справа налево и из глубины на поверхность. Тестированием выбора можно управлять с помощью различных флагов, включая HitTestable, который определяет, является ли визуал тестируемым по выбору (его значение по умолчанию - «истина»), и HitTestFinal, который определяет, останавливается ли тестирование выбора при выборе визуала, т.е. если визуал выбран и свойство HitTestFinal визуала имеет значение «истина», то тестирование выбора прекращается и возвращает результаты, собранные до этого момента (его значение по умолчанию - «ложь»). Еще одним флагом является HitTestIgnoreChildren, который определяет, следует ли рассматривать потомков визуала, когда тестирование выбора осуществляется на визуале (его значение по умолчанию - «ложь»).
Визуал-посредник (ProxiVisual) - это визуал, который можно добавлять в граф сцены более одного раза. Поскольку к любому визуалу, на который ссылается визуал-посредник, можно прийти от корня несколькими путями, услуги чтения (TransformToDescendant, TransformFromDescendant и HitTest) не работают через визуал-посредник. В сущности, имеется один канонический путь от каждого визуала к корню дерева визуалов, и этот путь не включает в себя визуалов-посредников.
Согласно фиг.5 в объектной модели заданы различные типы визуалов, в том числе визуалы-контейнеры (ContainerVisual) 501, визуалы рисования (DrawingVisual) 502, визуалы удостоверения (ValidationVisual) 503, визуалы поверхности (SufaceVisual) 504 и визуалы HWnd (HWndVisual) 505. В нижеследующей таблице приведены иллюстративные методы визуала рисования:
Визуал рисования является контейнером для графического контента (например, линий, текста, изображений и т.д.). Заметим, что визуал можно добавлять в визуал рисования, но в некоторых реализациях это недопустимо. Визуал рисования 502 содержит метод открытия (Open), который возвращает IDrawingContext, который можно использовать для заполнения визуала рисования, например, другими визуалами и примитивами рисования, что описано ниже. В одной реализации, по разным причинам также описанной ниже, визуал рисования можно открывать только один раз, чтобы заполнить его контекстом рисования; иными словами, такой визуал рисования является неизменяемым. После заполнения визуал рисования закрывается с использованием метода закрытия (Close), например, на контексте рисования. Заметим, что вызов открытия может очищать любые контенты (потомки) визуала, однако в одной альтернативной реализации предусмотрен метод присоединения (Append), позволяющий открывать текущий визуал с присоединением к этому визуалу. Другими словами, вызов OpenForAppend работает, как Open за исключением того, что текущий контент визуала рисования не очищается при открытии.
Ниже приведен пример, как контекст рисования используется для заполнения визуала:
В целом, визуал удостоверения (ValidationVisual) 503 концептуально аналогичен визуалу рисования за исключением того, что визуал удостоверения заполняется, когда система требует выполнения его заливки, а не когда программный код хочет заполнить его. Например, как описано в патентной заявке США № 10/185,775, высокоуровневая машина 214 наложения и анимации (фиг.2) может отменить данные графа сцены, когда требуются ресурсы, например, когда часть графа сцены не видна. Например, если некоторые части выходят за пределы экрана, отсекаются и т.д. Если отмененные данные потребуются в будущем, вызванный программный код 202 будет вызван повторно, чтобы повторно нарисовать (удостоверить) отмененный фрагмент графа сцены. Для этого один типичный сценарий использования предназначен для того, чтобы программный код подразделил визуал удостоверения и подменил метод OnValidate. Когда система вызывает метод OnValidate, ему передается контекст рисования, программа использует контекст рисования для повторного заполнения визуала удостоверения.
В нижеприведенном примере показан один способ реализации простого визуала удостоверения, например, рисующего линию определенного цвета. Цвет линии можно изменять, вызывая процедуру SetColor. Чтобы принудительно обновить визуал удостоверения, SetColor вызывает Invalidate, чтобы принудить графическую подсистему повторно удостоверить визуал удостоверения:
Этот пример показывает, как использовать визуал удостоверения:
На фиг.4 представлен пример графа 400 сцены, в котором визуалы-контейнеры и визуалы рисования связаны в графе сцены и снабжены соответствующими данными в виде примитивов рисования, (например, в соответствующих контекстах рисования). Визуал-контейнер (ContainerVisual) является контейнером для визуалов, и визуалы-контейнеры могут быть вложены друг в друга. Потомками визуала-контейнера можно манипулировать с помощью «совокупности визуалов» (VisualCollection), возвращаемой свойством «потомки» (Children) визуала-контейнера. Порядок визуалов в совокупности визуалов определяет порядок визуализации визуалов, т.е. визуалы визуализируются от наименьшего индекса к наибольшему индексу с заднего плана к переднему плану (в порядке рисования). Например, при надлежащих параметрах с помощью трех визуалов рисования, представляющих красный, зеленый и синий прямоугольники иерархически под визуалом-контейнером, следующий код будет приводить к рисованию трех прямоугольников (со сдвигом вправо и вниз), красный прямоугольник на заднем плане, зеленый прямоугольник посередине и синий прямоугольник на переднем плане:
На фиг.5 показан еще один тип визуального объекта - визуал поверхности (SurfaceVisual) 504. В общем случае, согласно фиг.3, объект 315 SurfaceVisual связан с поверхностью, хранящейся в памяти, (растровым изображением) 322, к которой может обращаться программный код 202 (фиг.2). Программный код-клиент 202 может поддерживать собственную память поверхностей или может требовать, чтобы память выделялась объектом «поверхность».
Программный код 202 имеет опцию открывать визуал поверхности и получать контекст рисования 323, в который программный код 202 может записывать пиксельные данные 324 и пр. и непосредственно помещать эти пиксели на поверхность. Это отражено на фиг.3 пунктирной линией между объектом 322 «поверхность», контекстом рисования 323 (показанным в виде пунктирного прямоугольника, чтобы отразить его временный характер) и пиксельными данными 324.
Программный код 202 также имеет опцию создавать менеджер 330 визуалов поверхности и связывать подграф 332 визуалов с визуалом поверхности 315. Эта опция представлена на фиг.3 пунктирной линией между объектом 322 «поверхность» и менеджером 330 визуалов поверхности. Заметим, что подграф 332 визуалов также допускает вложение других визуалов поверхности, что также показано на фиг.3. Менеджер 330 визуалов поверхности (также показанный как тип другого объекта в наборе 620 на фиг.6) обходит подграф 332 визуалов для обновления растрового изображения 322 визуала поверхности. Далее, заметим, что этот обход планируется диспетчером 308 и для эффективности может управляться для регулировки частоты обновления этого растрового изображения 322. Менеджеру 330 визуалов поверхности не приходится обходить подграф 332 визуалов каждый раз и/или с той же частотой, с какой менеджер 302 визуалов верхнего уровня обходит остальной граф сцены. В отношении поверхностей, как описано ниже со ссылкой на фиг.9А-9С, в целом, настоящая модель графики позволяет накладывать ряд визуалов на поверхность, визуализировать в прямом режиме векторные и растровые примитивы в поверхность, накладывать поверхность на рабочий стол или на другую поверхность и управлять, какую поверхность в списке поверхностей использовать для наложения на нее или рисования на ней. Список поверхностей задают как совокупность из одной или нескольких поверхностей (т.е. кадров/буферов) физической (системной или видео) памяти, используемых для хранения композиций визуалов или графических рисунков, или и того и другого. Одну поверхность из списка поверхностей можно задать в качестве текущего буфера заднего плана, где выполняется рисование и/или наложение, и одну поверхность из списка поверхностей задают в качестве текущего первичного буфера или буфера переднего плана, который используется для наложения на другую цель визуализации.
Поверхности можно использовать по-разному. Например, на фиг.9А показано наложение на поверхность. Согласно фиг.9А, объект 900 «менеджер визуалов поверхности» связан со списком 902 поверхностей, который является целью визуализации для дерева 904 визуалов. В каждом цикле наложения визуалы накладываются на поверхность из списка поверхностей, которая в данный момент служит активным буфером заднего плана для списка поверхностей. Поверхность, на которую производится наложение, может включать в себя поверхность, находящуюся в распоряжении клиента/ высокоуровневой машины 214 наложения (фиг.2) для внутрипроцессных сценариев наложения, поверхность, находящуюся в распоряжении низкоуровневой машины 218 наложения для сценариев, где клиент не нуждается в битах, но низкоуровневая машина 218 наложения нуждается в них для наложения поверхности на другую цель визуализации или кросс-процессную поверхность, для сценариев, где клиент нуждается в доступе к битам поверхности, но низкоуровневая машина 218 наложения также нуждается в поверхности для других действий наложения.
Наложение осуществляется под управлением услуги хронирования, присоединенной к менеджеру визуалов. Одним примером услуги хронирования является ручной режим, пример использования которого приведен ниже:
Другой путь использования поверхности состоит в прямой визуализации на поверхности через контекст. Присоединив список поверхностей к визуалу (визуалу поверхности) можно осуществлять прямую визуализацию на поверхности из списка поверхностей, которая в данный момент служит активным буфером заднего плана для списка поверхностей. Эту визуализацию осуществляют, получая контекст рисования из визуала поверхности и выполняя на этом контексте команды рисования, согласно описанному выше. Заметим, что получение контекста рисования блокирует поверхность, не позволяя выполнять другие операции наложения на нее. Каждая команда рисования выполняется немедленно, и векторы и другие поверхности можно рисовать (смешивать) на поверхности. Однако другие визуалы нельзя нарисовать на поверхности, но зато можно наложить на поверхность, связав ее с менеджером визуалов, согласно описанному ранее (например, на фиг.9А).
Еще один способ использования поверхностей состоит в наложении поверхности на другую цель визуализации. Для этого, присоединив список поверхностей к визуалу поверхности, поверхность можно присоединить в качестве узла в дереве визуалов, и поверхность из списка поверхностей, которая в данный момент служит первичным буфером или буфером переднего плана, можно наложить на другую поверхность или на рабочий стол.
Это проиллюстрировано на фиг.9В и в нижеприведенном примере:
Непосредственное наложение на/с поверхность/и представлено на фиг.9С, где вышеописанные возможности объединены так, что наложение на поверхность буфера заднего плана из списка поверхностей и наложение из поверхности буфера переднего плана из списка поверхностей (например, на рабочий стол) осуществляются одновременно. Заметим, что, чтобы исключить нежелательный видеоэффект, так называемый разрыв изображения, список поверхностей должен содержать, по меньшей мере, две поверхности, поверхности буферов переднего и заднего плана. Поверхность, используемая согласно фиг.9С, скорее всего, находится в распоряжении низкоуровневой машины 218 или является кросс-процессной поверхностью для улучшения наложения, осуществляемого в низкоуровневой машине 218.
Поверхности строятся как независимые объекты, что указано в нижеприведенных примерах конструкторов:
После построения поверхность и/или список поверхностей можно присоединить к объекту «визуал поверхности» или к объекту «менеджер визуалов».
Далее, поверхность может получить данные от декодера и/или послать свои данные на кодер для записи в конкретном файловом формате. Поверхности могут также принимать/посылать данные с/на интерфейсов/ы эффектов. Поверхность можно строить для любого пиксельного формата из полного набора поддерживаемых типов формата поверхности. Однако допустимы некоторые настройки заданного пиксельного формата, например, если заданный пиксельный формат составляет менее 32 битов на пиксель, то формат можно довести до 32 битов на пиксель. Всякий раз, когда биты запрашиваются с поверхности в исходном формате, поверхность будет копироваться в буфер запрашиваемого пиксельного формата с использованием фильтра преобразования формата.
На фиг.5 показан еще один визуал, а именно визуал HWnd (HwndVisual) 505, который размещает дочерний объект HWnd Win32 в графе сцены. В частности, существующие программы по-прежнему работают с применением метода WM_PAINT (или подобного), который рисует в дочерний HWnd (или подобный объект) на основании имеющейся технологии графики. Для поддержки этих программ в новой модели обработки графики визуал HWnd допускает, чтобы HWnd содержался в графе сцены и перемещался по мере повторного размещения родительского визуала, что представлено на фиг.10А. Однако в результате ограничений, присущих существующим HWnd, при визуализации дочерний HWnd может располагаться только поверх других окон и не подлежит повороту или масштабированию в отличие от других вышеописанных визуалов. Возможно некоторое отсечение, показанное на фиг.10В, где пунктирные линии указывают отображаемый прямоугольник HWnd, отсекаемый в процессе относительного перемещения по отношению к его родительскому визуалу.
Допустимы и другие типы визуалов 506, и данная объектная модель допускает расширение, позволяющее другим развивать ее. Например, согласно фиг.11 многослойный визуал 1100 позволяет разработчику приложений отдельно управлять информацией в визуале посредством нескольких потоков данных, обеспечивая повышенную степень детализации управления по сравнению с визуалами, имеющими один поток данных. Заметим, что аналогичной степени детализации управления можно добиться, имея (например, три) отдельных дочерних визуала под одним родительским визуалом, однако для этого требуется, чтобы программный код работал с несколькими визуалами, что сложнее, чем работа с одним многослойным визуалом, имеющим указатели на множественные слои.
Например, согласно фиг.11 данные фона, данные контекста и данные границы содержатся в одном многослойном визуале, но отделены друг от друга посредством указания значения слоя, например 0, 1 или 2 соответственно. Слои можно вставлять, в том числе присоединять с любого конца, и/или удалять, причем порядок расположения слоев (например, слева направо, как показано) задает предполагаемый Z-порядок отображения. Заметим, что для безопасности дочерние контент и другие данные в многослойном визуале не должны быть перечислимыми.
Другие типы визуалов включают в себя визуалы-контейнеры и перенаправленные дочерние визуалы HWnd, в которых контент рисуется в растровое изображение и включается в состав визуала поверхности. Трехмерные визуалы обеспечивают связь между двухмерным и трехмерным мирами, например, с помощью двухмерного визуала, имеющего вид в трехмерный мир, можно создать вид, подобный тому, который дает видеокамера.
Многие из объектов «ресурс» являются неизменяемыми после создания, т.е. после того, как они созданы, их нельзя менять по различным причинам, включая вопросы упрощения организации поточной обработки, предотвращение повреждения другими и упрощение взаимодействия с элементами и API. Заметим, что это, в целом, упрощает систему. Однако следует заметить, что допустимо иметь систему, где такие объекты являются изменяемыми, но, например, требующими управления графом зависимости. Например, хотя возможно иметь систему, где такие объекты изменяемы, если программный код изменит отсечение, установленное на визуале, то визуал потребуется повторно визуализировать, для чего необходим механизм извещения/регистрации, например, если визуалу присваивают новое отсечение, то визуал регистрирует себя с отсечением для извещений (например, извещения об изменении отсечения). Таким образом, в одном варианте реализации в целях упрощения объекты «ресурс» являются неизменяемыми.
Эти объекты «ресурс» можно задавать с помощью конструктора, что является простым, обычным способом создания объекта, или с использованием сопровождающего объекта «построитель», что описано ниже. Например, чтобы создать SolidColorBrush (объекты «кисть» описаны ниже), можно использовать конструктор:
Brush MyBrush = new SolidColorBrush(Colors.Red).
Пользователь также может использовать статические элементы класса Brushes (кисти), чтобы получать набор заранее заданных цветов.
Поскольку неизменяемые объекты нельзя изменять, то, чтобы эффективно изменить объект, пользователю нужно создать новый объект и заменить старый объект новым. Для этого многие объекты «ресурс» в системе могут использовать шаблон построителя, в котором неизменяемые объекты создаются с помощью класса построителя, который является сопровождающим классом, допускающим изменения. Пользователь создает неизменяемый объект, чтобы отобразить набор параметров на построитель, создает новый построитель для этого объекта и инициализирует его из неизменяемого объекта. Затем пользователь изменяет построитель по мере необходимости. После этого пользователь может строить новый объект, изменяя построитель и повторно используя его для создания другого неизменяемого объекта. Заметим, что желательно иметь неизменяемые объекты с заданными свойствами и что неизменяемые объекты нельзя изменять, но лишь заменять, активизируя событие изменения свойства.
Таким образом, вместо того чтобы использовать конструктор для создания SolidColorBrush, как описано выше, можно использовать SolidColorBrushBuilder:
SolidColorBrushBuilder MyBuilder = new;
SolidColorBrushBuilder();
MyBuilder.Color = Colors.Red;
Brush MyBrush = MyBuilder.ToBrush().
Большинство объектов, которые принимают статические значения, могут также принимать объекты анимации. Например, на DrawingContext имеется замещение на DrawCircle, которая принимает PointAnimationBase для центра круга. Таким образом, пользователь может задавать богатую анимационную информацию на уровне примитивов. Для объектов «ресурс» существует совокупность анимации в дополнение к базовому значению. Они накладываются, за счет чего, если пользователь пожелает анимировать вышеприведенный пример, то пользователь, прежде чем построить кисть, сможет задать следующую иллюстративную строку:
MyBuilder.ColorAnimations.Add(new ColorAnimation(...)).
Заметим, что объект с параметрами анимации по-прежнему является неизменяемым, поскольку его параметры анимации являются статическими. Однако при обработке графа сцены (например, обходе) значение параметров анимации изменяется с течением времени, из-за чего появляются анимационные, нестатические данные.
Согласно вышеописанному визуалы можно рисовать, заполняя их контекстами рисования с помощью различных примитивов рисования, в том числе «геометрия» (Geometry), «данные изображения» (ImageData) и «видеоданные» (VideoData). Кроме того, имеется набор ресурсов и классов, которые совместно используются всей этой группой. Они включают в себя перья, кисти, геометрию, трансформации и эффекты. IDrawingContext представляет набор операций рисования, которые можно использовать для заполнения DrawingVisual (визуала рисования), ValidationVisual (визуала удостоверения). ISurfaceDrawingContext, основной интерфейс с контекстом IDrawing, можно использовать для заполнения SurfaceVisual (визуала поверхности). Иными словами, контекст рисования представляет набор операций рисования; для каждой операции рисования имеется два метода: один, который принимает в качестве аргументов константы, и другой, который принимает в качестве аргументов аниматоры. Метод DrawLine рисует линию с помощью заданного пера от начальной точки до конечной точки.
Метод DrawRoundedRectangle рисует сглаженный прямоугольник с помощью заданных кисти и пера; кисть и перо могут иметь значение null.
Метод DrawGeometry рисует путь с помощью заданных кисти и пера; кисть и перо могут иметь значение null.
Метод DrawRectangle рисует прямоугольник с помощью заданных кисти и пера; кисть и перо могут иметь значение null.
Метод DrawSurface рисует поверхность.
Геометрия (Geometry) - это тип класса (фиг.12), который задает скелет векторной графики, без обводки или заливки. Каждый объект «геометрия» является простой формой (LineGeometry (геометрия линии), EllipsGeometry (геометрия эллипса), RectangleGeometry (геометрия прямоугольника)), сложной единой формой (PathGeometry (геометрия пути)) или списком таких форм GeometryList (список геометрий) с заданной соединительной операцией (например, объединения, пересечения и т.д.).
Согласно фиг.13 геометрия пути PathGeometry представляет собой совокупность объектов «фигура» (Figure). В свою очередь, каждый объект «фигура» состоит из одного или нескольких объектов «сегмент» (Segment), которые фактически задают форму фигуры. Фигура является подразделом геометрии Geometry, который задает совокупность сегментов. Эта совокупность сегментов является последовательностью соединенных один за другим двухмерных объектов «сегмент». Фигура может представлять собой либо замкнутую форму с определенной областью, либо просто последовательностью соединенных сегментов, которые задают кривую, но не замкнутую область.
Залитую область геометрии пути PathGeometry задают, выбирая содержащиеся фигуры, у которых свойство «заливка» (Filled) имеет значение «истина», и применяя FillMode (режим заливки) для определения замкнутой области. Заметим, что FillMode перечислимого типа задает, как пересекающиеся области объектов «фигура», содержащихся в «геометрии», объединяются, образуя результирующую область «геометрии». Правило «чередования» позволяет определить, находится ли точка внутри холста. Для этого нужно мысленно провести луч из этой точки до бесконечности в любом направлении, а затем отметить места, где сегмент формы пересекает луч. Затем нужно начать отсчет с нуля и добавлять единицу всякий раз, когда сегмент пересекает луч слева направо, и вычитать единицу всякий раз, когда сегмент пути пересекает луч справа налево. Если подсчет пересечений даст результат, равный нулю, то точка находится вне пути. В противном случае она находится внутри. Правило «намотки» позволяет определить, находится ли точка на холсте внутри. Для этого нужно мысленно провести луч из этой точки до бесконечности в любом направлении и подсчитать число сегментов пути из данной формы, которые этот луч пересекает. Если это число нечетное, то точка находится внутри; если четное - то вне. Согласно фиг.14 при рисовании геометрии (например, прямоугольника) можно задавать кисть или перо, что описано ниже. Кроме того, объект «перо» также имеет объект «кисть». Объект «кисть» задает, как графически заливать плоскость, и имеется иерархия классов объектов «кисть». Это представлено на фиг.14 залитым прямоугольником 1402, который получается при обработке визуала, содержащего прямоугольник и команды и параметры кисти.
Согласно описанному ниже некоторые типы кистей (например, градиенты и девятиячеечные сетки) сами определяют свой размер. При использовании размер этих кистей получают из ограничивающего окна, например, когда GradientUnits/DestinationUnits для Brush задано равным ObjectBoundingBox, используют ограничивающее окно вырисовываемого примитива. Если эти свойства заданы равными UserSpaceOnUse, то используют координатное пространство.
Объект «перо» (Pen) поддерживается кистью совместно со свойствами Width, LineJoin, LineCap, MiterLimit, DashArray и DashOffset, что представлено в нижеприведенном примере:
Как отмечено выше, объектная модель графики, отвечающая настоящему изобретению, включает в себя объектную модель кисти, задачей которой, в общем случае, является покрытие плоскости пикселями. Примеры типов кистей представлены в иерархии, изображенной на фиг.15, и в базовом классе кисти включают в себя кисть чистого цвета (SolidColorBrush), градиентную кисть (GradientBrush), кисть изображения (ImageBrush), кисть визуала (VisualBrush) (которая может ссылаться на визуал) и кисть девятиячеечной сетки (NineGridBrush). Градиентная кисть включает в себя объекты «линейный градиент» (LinearGradient) и «радиальный градиент» (RadialGradient). Согласно вышеприведенному описанию объекты «кисть» являются неизменяемыми.
Ниже приведен пример класса построителя кисти (BrushBuilder):
Заметим, что объекты «кисть» при использовании могут распознавать, как они связаны с системой координат и/или как они связаны с ограничивающим окном формы, на которой они используются. В общем случае информацию, например размер, можно извлекать из объекта, на котором рисует кисть. В частности, многие типы кисти используют систему координат для задания некоторых своих параметров. Эту систему координат можно либо задавать как связанную с простым ограничивающим окном формы, к которой применяется кисть, либо ее можно связывать с координатным пространством, которое является активным во время использования кисти. Это известные режимы ObjectBoundingBox и UserSpaceOnUse соответственно.
Объект «кисть чистого цвета» (SolidColorBrush) заливает указанную плоскость чистым (сплошным) цветом. При наличии компонента «альфа» цвета он объединяется путем умножения с соответствующим атрибутом непрозрачности в базовом классе «кисть». Ниже приведен пример объекта SolidColorBrush:
Объекты «градиентная кисть» (GradientBrush) или просто градиенты обеспечивают градиентную заливку и вырисовываются путем задания ряда остановок градиента, которые задают цвета совместно с некоторого рода прогрессией. Градиент рисует, осуществляя линейные интерполяции между остановками градиента в цветовом пространстве RGB с гаммой 2.2; допустимыми альтернативами являются также интерполяция по другим гаммам или другим цветовым пространствам (HSB, CMYK и т.д.). Существует два типа объектов «градиент», а именно линейный и радиальный градиенты.
В целом, градиенты состоят из списка остановок градиента. Каждая из этих остановок градиента содержит цвет (со включенным значением альфа) и смещение. Если ни одной остановки градиента не задано, то кисть рисует чистым прозрачным черным цветом, как будто кисть вообще не задана. Если задана только одна остановка градиента, то кисть рисует чистым цветом, одним заданным цветом. Как и другие классы ресурсов, класс остановок градиента (пример в нижеприведенной таблице) является неизменяемым.
Имеется также класс совокупности, описанный в нижеприведенном примере:
Согласно нижеприведенной таблице GradientSpreadMethod задает, как должен быть нарисован градиент вне заданного вектора или пространства. Существует три значения, включая «площадка» (pad), в которой краевые цвета (первый и последний) используются для заливки остального пространства, «отражение» (reflect), в котором остановки повторно воспроизводятся в обратном порядке для заливки пространства, и «повтор» (repeat), в котором остановки повторяются в прямом порядке, пока пространство не будет залито:
На фиг.16 показаны примеры GradientSpreadMethod. Каждая форма имеет линейный градиент, идущий от белого к серому. Сплошная линия представляет вектор градиента.
LinearGradient задает кисть с линейным градиентом вдоль вектора. Отдельные остановки задают цветовые остановки вдоль этого вектора. Пример показан в нижеследующей таблице:
RadialGradient имеет модель программирования, аналогичную линейному градиенту. Однако в то время, как линейный градиент задает вектор градиента с помощью начальной и конечной точек, радиальный градиент задает поведение градиента посредством окружности совместно с фокальной точкой. Окружность задает конечную точку градиента, т.е. остановка градиента на 1.0 задает цвет на окружности. Фокальная точка задает центр градиента. Остановка градиента на 0.0 задает цвет в фокальной точке.
На фиг.17 показан радиальный градиент от белого к серому. Внешняя окружность представляет окружность градиента, тогда как точка обозначает фокальную точку. В этом иллюстративном градиенте SpreadMethod задан равным Pad:
Другой объект «кисть», представленный на фиг.15, - это объект «кисть визуала» (VisualBrush). В принципе, кисть визуала обеспечивает способ рисования визуала повторяющимся, мозаичным способом, наподобие заливки. Объекты раскраски визуала также обеспечивают механизм, позволяющий языку разметки непосредственно работать с уровнем API на уровне ресурсов, как описано ниже. В качестве примера такой заливки на фиг.14 представлена кисть визуала, ссылающаяся на визуал (и любые дочерние визуалы), который задает единичную круговую форму 1420, и заливает этой круговой формой прямоугольник 1422. Таким образом, объект «кисть визуала» может ссылаться на визуал, чтобы задавать, как должна рисовать эта кисть, что вводит тип множественного использования для визуалов. Таким образом, программа может использовать «метафайл» произвольной графики, чтобы заливать область с помощью кисти или пера. Поскольку это сжатый вид хранения и использования произвольной графики, он выступает в качестве ресурса графики. Ниже приведен пример объекта «кисть визуала»:
Контенты кисти визуала не имеют встроенных границ и эффективно описывают бесконечную плоскость. Эти контенты существуют в своем собственном координатном пространстве, и пространство, заливаемое кистью визуала, является локальным координатным пространством на время применения. Пространство контентов отображается в локальное пространство в зависимости от свойств «окно видимости» (ViewBox), «окно просмотра» (ViewPort), «выравнивание» (Alignment) и «растяжение» (Stretch). Окно видимости задано в пространстве контентов, и этот прямоугольник отображается в прямоугольник окна просмотра (заданный посредством свойств Origin (начало отсчета) и Size (размер)).
Окно просмотра задает место, где в конечном итоге будут нарисованы контенты, создавая базовый элемент мозаики для этой кисти. Если значение DestinationUnits равно UserSpaceOnUse, то свойства Origin и Size рассматривают в локальном пространстве на время применения. Если вместо этого значение DestinationUnits равно ObjectBoundingBox, то свойства Origin и Size рассматривают в координатном пространстве, где (0,0) это левый верхний угол ограничивающего окна объекта, визуализируемого кистью, а (1,1) это правый нижний угол того же окна. Например, рассмотрим заливаемый объект RectangleGeometry, нарисованный от (100,100) до (200,200). В этом примере, если DestinationUnits имеет значение ObjectBoundingBox, то Origin, равное (0,0), и Size, равное (1,1), будут описывать всю область контента. Если Size пусто, то эта «кисть» ничего не визуализирует.
Окно видимости ViewBox задают в пространстве контентов. Этот прямоугольник трансформируют, чтобы вписать его в окно просмотра, в соответствии со свойствами «выравнивание» и свойством «растяжение». Если «растяжение» равно «none», то контенты не подвергаются масштабированию. Если свойство «растяжение» имеет значение Fill (залито), то окно видимости масштабируют независимо в направлениях X и Y, чтобы придать ему такой же размер, как у окна просмотра. Если «растяжение» имеет значение Uniform или UniformToFill, то логика аналогична, но размеры X и Y масштабируют однородно, сохраняя форматное отношение контентов. Если «растяжение» имеет значение Uniform, то окно видимости масштабируют, чтобы придать ему более ограниченный размер, равный размеру окна просмотра. Если «растяжение» имеет значение UniformToFill, то окно видимости масштабируют, чтобы придать ему менее ограниченный размер, равный размеру окна просмотра. Другими словами, как Uniform, так и UniformToFill сохраняет форматное отношение, но Uniform гарантирует, что все окно видимости находится внутри окна просмотра (потенциально оставляя участки окна просмотра непокрытыми окном видимости), а UniformToFill гарантирует, что все окно просмотра заполнено окном видимости (потенциально заставляя участки окна видимости быть вне окна просмотра). Если окно видимости пусто, то никакое растяжение (Stretch) не применяется. Заметим, что выравнивание применяется даже в этом случае, и оно позиционирует «точечное» окно видимости.
На фиг.18 показаны представления единичного элемента 1800 мозаики в графике, визуализируемой при различных установках растяжения, в том числе элемент 1800 мозаики, где установлено растяжение, равное none (отсутствие). Элемент 1802 мозаики представляет растяжение, имеющее значение Uniform, элемент 1804 мозаики представляет растяжение, имеющее значение UniforfToFill, и элемент 1806 мозаики представляет растяжение, имеющее значение Fill.
Определив окно просмотра (на основании DestinationUnits) и определив размер окна видимости (на основании Stretch), нужно позиционировать окно видимости в окне просмотра. Если окно видимости имеет такой же размер, что и окно просмотра (если Stretch равно Fill, или если оно просто случайно оказалось с одним из трех других значений Stretch), то окно видимости позиционируется в начале отсчета, чтобы совпадать с окном просмотра. В противном случае применяются выравнивание по горизонтали и выравнивание по вертикали. На основании этих свойств окно видимости выравнивают в направлениях X и Y. Если «выравнивание по горизонтали» принимает значение Left, то левый край окна видимости совмещают с левым краем окна просмотра. Если это свойство принимает значение Center, то центр окна видимости совмещают с центром окна просмотра, а если Right, то совмещают правые края. Тот же процесс применяют для направления Y.
Если окно видимости равно (0,0,0,0), его считают неустановленным, в связи с чем рассматривают свойство ContentUnits. Если свойство ContentUnits принимает значение UserSpaceOnUse, то никакого масштабирования или смещения не производят и вырисовывают контенты в окне просмотра без какой-либо трансформации. Если ContentUnits принимает значение ObjectBoundingBox, то начало отсчета контента совмещают с началом отсчета окна просмотра и масштабируют контенты по ширине и высоте ограничивающего окна объекта.
При заливке пространства с помощью кисти визуала контенты отображаются в окно просмотра, как описано выше, и отсекаются по окну просмотра. Получается базовый элемент мозаики для заливки, а остальное пространство заливают в зависимости от значения TileMode кисти. Наконец, применяют трансформацию кисти, если таковая установлена, ее производят после всех других операций отображения, масштабирования, смещения и пр. Свойство TileMode перечислимого типа используют для описания, заливать ли и как заливать пространство кистью, с которым связано это свойство. Кисть, которую можно снабдить элементом мозаики, имеет заданный прямоугольник элемента мозаики, и этот элемент мозаики имеет базовое местоположение в заливаемом пространстве. Остальное пространство заливают в зависимости от значения TileMode. На фиг.19 показано представление иллюстративной графики с различными установками TileMode, включая «None» 1900, «Tile» 1902, «FlipX» 1904, «FlipY» 1906 и «FlipXY» 1908. Левый верхний элемент мозаики в различных иллюстративных графиках представляет собой базовый элемент мозаики.
На фиг.20 представлен процесс генерации пикселей для этой кисти. Заметим, что логика, описанная на фиг.20, является лишь одним возможным вариантом реализации логики, и следует понимать, что допустимы другие, в том числе более эффективные, варианты. Например, наверняка существуют более эффективные способы обработки данных, например, когда контент не вырисовывают при каждом повторе, причем элемент мозаики вырисовывают и кэшируют. Однако фиг.20 предоставляет простое описание.
В общем случае, всякий раз при вырисовке контентов шаблона, создают новую систему координат. Начало отсчета и смещение каждого представления задают посредством свойств Origin и Size, отфильтрованных посредством свойств DestinationUnits и Transform.
Систему координат задают на основании свойства DestinationUnits. Для этого, если на этапе 2000 определяют, что свойство DestinationUnits имеет значение UserSpaceOnUse, то на этапе 2002 текущую систему координат на момент использования кисти назначают начальной системой координат. Если же на этапе 2000 определяют, что это свойство имеет значение ObjectBoundingBox, то на этапе 2004 используют ограничивающее окно геометрии, к которой применяется эта кисть, чтобы задать новую систему координат, в которой левый верхний угол ограничивающего окна отображается на (0,0), и левый нижний угол ограничивающего окна отображается на (1,1). В любом случае на этапе 2006, к этой системе координат применяют свойство Transform, которое фактически задает сетку.
На фиг.21 представлена сетка кисти визуала, задаваемая для элементов мозаики в кисти визуала. Первый круг представляет собой простую сетку, а второй круг получен трансформацией перекоса (Skew) в направлении Х, равного 47.
На этапе 2008 в каждой ячейке сетки вырисовывают визуал, что показано на фиг.22, где визуал вырисовывает соответствующие данные. Если на этапе 2010 определяют, что окно видимости задано, то на этапе 2012 визуал умещают в ячейку сетки в соответствии с атрибутами ViewBox, Stretch, HorizontalAlign, VerticalAlign. Свойства DestinationUnits и Transform используют для применения правильной трансформации, чтобы центрировать визуал в ячейке сетки.
Если ViewBox не задано, на этапе 2014 устанавливают новую систему координат для нарисовки контента.
Систему координат задают таким образом, чтобы ее начало отсчета совпадало с началом отсчета (Origin) данной конкретной ячейки сетки, в которой производится рисование.
На этапе 2018 применяют отсечение на основании свойства Size, чтобы этот элемент мозаики не был нарисован вне границ ячейки. Origin и Size соответствующим образом модифицируют на основании свойства DestinationUnits.
Затем модифицируют систему координат на основании свойства SourceUnits. Для этого если на этапе 2020 определяют, что свойство SourceUnits имеет значение ObjectBoundingBox, то на этапе 2022 применяют соответствующую трансформацию масштабирования, в противном случае, если оно равно UserSpaceOnUse, никакой новой трансформации не применяют. На этапе 2024 применяют свойство Transform, и на этапе 2026 вырисовывают контент.
Заметим, что если какая-либо составляющая свойства «размер» равна нулю, то ничего не рисуют, и если растяжение имеет значение None, то трансформацию окна видимости (ViewBox) задают так, чтобы одна единица в новой системе координат была равна одной единице в старой системе координат. Трансформация, по существу, превращается в смещение, зависящее от атрибутов выравнивания и размера окна видимости. Как описано выше, на этапах 2010 и 2012 свойства «растяжение» и «выравнивание» применяют только тогда, когда задано окно видимости. Окно видимости задает новую систему координат для контентов, а «растяжение» помогает задать, как отображать эти контенты в окно видимости. Опции выравнивания выравнивают окно видимости, но не контенты. Таким образом, например, если окно видимости задано равным "0 0 10 10" и что-то нарисовано в (-10,-10) и выравнено по левому верхнему углу, то это изображение будет отсечено.
Согласно фиг.15 кисть изображения можно рассматривать как частный случай кисти визуала. Хотя программа может создавать визуал, помещать в него изображение и присоединять его к кисти визуала, API для этих операций будет громоздким. Ввиду отсутствия необходимой системы координат контента элементы свойств ViewBox и ContentUnits уже не применяются.
Кисть девятиячеечной сетки NineGridBrush во многом аналогична кисти изображения ImageBrush за исключением того, что изображение деформируется в зависимости от размера. В сущности, кисть девятиячеечной сетки можно рассматривать как специализированный тип растяжения, в котором определенные части изображения растягиваются, тогда как другие (например, границы) - нет. Таким образом, в то время как в зависимости от размера изображения в кисти изображения осуществляется простое масштабирование, кисть девятиячеечной сетки обеспечивает неоднородное масштабирование до нужного размера. Единицы для немасштабированных областей являются пользовательскими единицами при применении кисти, т.е. ContentUnits (если бы он существовал для девятиячеечной кисти) следовало бы задать равным UserUnitsOnUse. Свойство Transform кисти можно использовать эффективно. Заметим, что в элементы границы входят края изображения.
Например, на фиг.23 показано изображение девятиячеечной сетки, увеличиваемое от первого примера 2302 до второго примера 2304, с четырьмя типами областей. Согласно фиг.23, чтобы сохранить форму границы, области, помеченные «а», расширяют по горизонтали, области, помеченные «b», расширяют по вертикали, области, помеченные «с», расширяют по горизонтали и по вертикали, и области, помеченные «d», не изменяют по размеру.
Согласно описанному в общих чертах выше объектная модель графики, отвечающая настоящему изобретению, включает в себя объектную модель трансформации (Transform), которая включает в себя типы трансформаций, представленных в иерархии, показанной на фиг.24, под базовым классом «трансформация». Эти разные типы компонентов, которые осуществляют трансформацию, могут включать в себя «список трансформаций» (TransformList), «трансформация переноса» (TranslateTransform), «трансформация поворота» (RotateTransform), «трансформация масштабирования» (ScaleTransform), «трансформация перекоса» (SkewTransform) и «матричная трансформация» (MatrixTransform). Отдельные свойства можно анимировать, например, разработчик программ может анимировать свойство «угол» (Angle) трансформации поворота.
Матрицы для 2-мерных расчетов представлены в виде матрицы 3×3. Для нужных трансформаций требуется только шесть значений вместо полной матрицы 3×3. Они снабжены именами и заданы следующим образом:
Матрица, умножаемая на точку, трансформирует эту точку из новой системы координат к предыдущей системе координат:
Трансформации могут быть вложенными до любого уровня. Применение каждой новой трансформации эквивалентно умножению ее справа на матрицу текущей трансформации:
Большинство мест в API не принимают матрицу (Matrix) непосредственно, но вместо этого используют класс «трансформация», поддерживающий анимацию.
Язык разметки и объектная модель векторной графики
В соответствии с аспектом настоящего изобретения предусмотрены язык разметки и объектная модель элементов, которые позволяют пользовательским программам и инструментам взаимодействовать со структурой 216 данных графа сцены, не требуя конкретного знания деталей уровня 212 API (фиг.2). В целом, предусмотрен язык разметки векторной графики, который содержит формат обмена совместно с простым форматом авторской системы на основе разметки для выражения векторной графики посредством объектной модели элементов. С помощью этого языка можно программировать разметку (например, контент типа HTML или XML). Затем, чтобы построить граф сцены, разметку анализируют и транслируют в соответствующие объекты уровня API визуалов, которые были описаны выше. На этом более высоком операционном уровне предусмотрены элементное дерево, система свойств и система презентаторов, которые берут на себя наиболее громоздкую обработку, тем самым снабжая конструкторов сцен простыми средствами, позволяющими конструировать даже весьма сложные сцены.
В целом, система векторной графики обычно предусматривает набор элементов «форма» и других элементов, объединение с системой общих свойств, систему группирования и наложения и двухуровневый подход (на уровне элементов и уровне ресурсов), что позволяет пользователю программировать таким образом, чтобы удовлетворять требованиям гибкости и производительности. Согласно одному аспекту настоящего изобретения объектная модель элементов для работы с векторной графикой коррелирует с объектной моделью графа сцены. Другими словами, система векторной графики и уровень API визуалов совместно пользуются набором ресурсов на уровне объектной модели элементов, например, объект «кисть» используется при вырисовке на API визуалов и также является типом свойства заливки на «форме» (Shape). Таким образом, язык разметки не только имеет элементы, коррелирующие с объектами графа сцены, но также совместно с уровнем API визуалов пользуется рядом ресурсов примитивов (например, кистями, трансформациями и т.д.). Система векторной графики также предоставляет и расширяет анимационные возможности уровня API визуалов, подлежащего широкому совместному использованию между уровнями.
Кроме того, как описано ниже, система векторной графики может программировать на разных профилях, или уровнях, включая уровень элементов или уровень ресурсов. На уровне элементов каждая из форм рисования представлена элементом того же уровня, что и остальные программируемые элементы в странице/экране. Это значит, что формы в полной мере взаимодействуют с системой презентаторов, событиями и свойствами. На уровне ресурсов системы векторной графики действуют в чистом формате ресурса аналогично традиционному метафайлу графики. Уровень ресурсов эффективен, но имеет несколько ограниченную поддержку каскадированных свойств, обработки событий и программируемости с тонкой детализацией. Таким образом, конструктор сцены имеет возможность балансировать между эффективностью и программируемостью, по мере необходимости.
Согласно одному аспекту настоящего изобретения система векторной графики на уровне ресурсов также коррелирует (соотносится) с уровнем API визуалов в том, что разметка уровня ресурсов в одной из реализаций выражается в виде кисти визуала. При анализе разметки ресурса создают объект «визуал». Объект «визуал» устанавливают равным VisualBrush (кисть визуала), которая может использоваться формами, элементами управления и другими элементами на уровне элементов.
На фиг.25 представлена иерархия 2500 классов элементов. Классы объектной модели языка разметки, отвечающей настоящему изобретению, представлены прямоугольниками с тенью и включают в себя класс 2502 формы, класс 2504 изображения, класс 2506 видео и класс 2508 холста. Элементы класса формы включают в себя прямоугольник 2510, полилинию 2512, многоугольник 2514, путь 2516, линию 2518 и эллипс 2520. Заметим, что в некоторых реализациях элемент круг может не присутствовать, что указано пунктирным прямоугольником 2522 на фиг.25, однако здесь в целях различных примеров элемент 2522 «круг» будет описан. Каждый элемент может включать в себя данные (свойства) заливки, данные обводки, данные отсечения, данные трансформации, данные эффекта фильтра и данные маски или быть связанным с ними.
Как описано ниже, формы соответствуют геометрии, вырисовываемой с унаследованными и каскадированными свойствами презентации. Свойства презентации используют для построения пера и кисти, необходимых для рисования форм. В одной реализации формы являются полными презентаторами, как и другие элементы управления. Однако в других реализациях класс 2508 холста может быть предусмотрен как контейнер для форм, и формы можно рисовать только тогда, когда они находятся в элементе холста. Например, для обеспечения легкости форм можно не разрешать присоединять к формам презентаторы. Вместо этого холст имеет присоединенный презентатор и рисует формы. Элементы холста описаны ниже более подробно.
Также, как описано ниже, класс изображения является более специфическим, чем форма, и, например, может включать в себя данные границы, которые могут быть сложными. Например, границу можно задать посредством одного цвета сверху, другого цвета по бокам, возможно, различных заданных значений толщины и других свойств. Для изображения или аналогичного оконного элемента, например текста или видео, можно задавать позицию, размер, поворот и масштаб. Заметим, что элементы «изображение» и «видео» могут существовать и быть показаны вне элемента холста и также наследовать от оконного элемента, например получать фон, границы и поддержку набивки от этого элемента.
Элемент «видео» позволяет воспроизводить видео (или аналогичную мультимедийную информацию) в отображаемом элементе. Таким образом, система векторной графики обеспечивает интерфейс разметки для уровня API, который бесшовно согласуется с разными видами мультимедийной информации, включая текст, двухмерную графику, трехмерную графику, анимацию, видео, неподвижные изображения и аудио. Это позволяет конструкторам, привыкшим работать с одними средами, легко интегрировать другие среды в приложения и документы. Система векторной графики также позволяет анимировать мультимедийную информацию таким же образом, что и другие элементы, опять же дает возможность конструкторам использовать мультимедийную информацию, как другие элементы, не жертвуя при этом коренной внутренней уникальностью каждого отдельного типа сред. Например, конструктор может использовать одну и ту же схему имен для вращения, масштабирования, анимации, наложения и других эффектов в разных типах сред, что позволяет конструкторам легко создавать очень богатые приложения, а также позволяет встраивать в них очень эффективную реализацию визуализации и наложения.
На фиг.26 показана одна реализация, в которой код разметки 2602 интерпретируется анализатором/транслятором 2604. В общем случае, анализатор/транслятор 2604 добавляет элементы к дереву элементов / системе свойств 208 (также представленному на фиг.2) и присоединяет презентаторы к этим элементам. Система презентаторов 210 берет дерево элементов 210 с присоединенными презентаторами и транслирует данные в объекты и вызовы на уровень 212 API визуала. Заметим, что транслировать нужно не все элементы, а только те, к которым присоединены презентаторы. В общем случае, элемент - это объект на уровне элементов, который участвует в системе свойств, обработки событий и системе компоновки/презентации. Анализатор ищет тэги и решает, помогают ли эти тэги задавать элемент или объект ресурса. В частном случае кисти визуала, одни и те же тэги можно интерпретировать как элементы или также можно интерпретировать как объекты ресурсов, в зависимости от контекста, где эти тэги находятся, например в зависимости от того, находятся ли они в сложном синтаксисе свойства или нет.
Согласно одному аспекту настоящего изобретения язык разметки предусматривает различные пути описания ресурса, включая формат простой строки и сложную систему записи объекта. Для формата простой строки анализатор/транслятор 2604 использует преобразователь 2608 типов для преобразования строки в соответствующий объект API визуалов. Например, в нижеследующей строке разметки, значение свойства Fill можно преобразовывать в объект «кисть» посредством преобразователя 2608 типов:
Очевидно, что преобразование такой встроенной строки тэговой разметки с помощью простых строк параметров в объект «кисть» является непосредственным и обеспечивает конструктору сцены простой способ добавлять форму и ее атрибуты к сцене.
Однако случается так, что атрибут заливки слишком сложен, чтобы уместиться в простую строку. В этом случае для задания этого свойства используют сложный синтаксис свойства. Например, нижеследующий сложный синтаксис свойства описывает заливку круга с помощью градиента, а не чистого цвета, задавая цвета на различных остановках градиента (которые могут принимать значения от 0 до 1):
Экземпляр ресурса может быть представлен не только встроенным в разметку, но также может размещаться в другом месте (например, в разметке или файле, который может быть локальным или на удаленной сети и надлежащим образом загружаться), на который ссылаются по имени (например, текстовому имени, ссылке или другому подходящему идентификатору). Таким образом, конструктор сцены может повторно использовать элемент из элементного дерева в разных местах сцены, в том числе элементы, описанные с помощью сложного синтаксиса свойств.
Анализатор оперирует разметкой в сложном синтаксисе свойств, обращаясь, при необходимости, к преобразователю 2608 типов, а также согласуя заданные параметры со свойствами объекта, тем самым упрощая работу конструктора сцены. Таким образом, анализатор не просто задает объекты, но также задает атрибуты на объектах. Заметим, что анализатор фактически предписывает построителю создавать объекты, поскольку объекты являются неизменяемыми.
Поскольку уровень элементов и уровень API совместно используют одну и ту же модель визуализации, многие объекты, по существу, совпадают. Это повышает эффективность анализа/трансляции, а также позволяет языкам программирования разных типов (например, языкам, подобным C#) легко преобразовывать разметку в свой собственный синтаксис и наоборот. Заметим, что, согласно фиг.26, другой такой язык 2610 программирования может добавлять элементы в дерево 208 элементов или может напрямую взаимодействовать с уровнем 212 API визуалов.
Согласно фиг.26 и в соответствии с аспектом настоящего изобретения одну и ту же разметку 2602 можно использовать для программирования на уровне элементов и на уровне ресурсов. Согласно вышеописанному уровень элементов обеспечивает конструктору сцены полную программируемость, доступ к системе свойств, которая обеспечивает наследование (например, особенности типа таблицы стилей) и обработку событий (например, посредством которой к элементу можно присоединять код для изменения его внешнего вида, позиции и т.д. в порядке реакции на событие пользовательского ввода). Однако настоящее изобретение также предусматривает механизм уровня ресурсов, посредством которого конструкторы сцен могут существенно урезать дерево элементов и систему презентаторов и программировать непосредственно на уровне API визуалов. Для многих типов статических форм, изображений и т.п., где не требуются особенности уровня элементов, это обеспечивает более эффективный и легкий способ вывода соответствующего объекта. Для этого анализатор распознает, когда присутствует заливка типа «кисть визуала», и напрямую вызывает уровень 212 API с помощью данных 2612 уровня ресурсов для создания объекта. Другими словами, как показано на фиг.22, элементный уровень векторной графики анализируется в созданные элементы, подлежащие дальнейшей трансляции в объекты, тогда как ресурсный уровень векторной графики анализируется и непосредственно сохраняется эффективным способом.
Например, нижеследующая разметка непосредственно выводится из объектной модели для объекта «линейный градиент» и заливает пространство вне окружности с помощью кисти визуала. Контенты этой кисти визуала задаются внутренней разметкой. Заметим, что этот синтаксис обычно используется для выражения различных кистей, трансформаций и анимаций:
Заметим, что, хотя эти объекты, залитые с помощью кисти визуала, эффективно сохраняются, на данные уровня ресурсов (или созданные с их помощью объекты) можно ссылаться посредством элементов и части дерева 208 элементов, что в общем виде представлено на фиг.26. Для этого эти ресурсы кисти визуала следует снабжать именами (например, посредством имени, ссылки или другого подходящего идентификатора) и обеспечивать возможность ссылаться на них, наподобие других ресурсов, описанных с помощью сложного синтаксиса свойств.
Возвращаясь к объяснению холста, упомянутого выше в связи с одной альтернативной реализацией, можно облегчать формы и, таким образом, требовать, чтобы они содержались в холсте. В этой альтернативной реализации при визуализации контента он визуализируется на бесконечный аппаратно-независимый холст, с которым связана система координат. Элемент «холст» может, таким образом, позиционировать контент согласно абсолютным координатам. Элемент «холст» может в необязательном порядке задавать окно просмотра, которое задает отсечение, трансформацию, предпочтительное форматное отношение и способ отображения окна просмотра в родительское пространство. Если никакого окна просмотра не установлено, то элемент «холст» задает только группирование примитивов рисования и может устанавливать трансформацию, непрозрачность и другие атрибуты наложения.
Ниже приведен пример разметки для образца холста:
Заметим, что в одной реализации, когда координаты заданы без единиц, их рассматривают как «логические пиксели» по 96 на дюйм, и в вышеприведенном примере линия будет иметь 200 пикселей в длину. Помимо координат, другие свойства включают в себя ширину, высоту, выравнивание по горизонтали и по вертикали и окно видимости (ViewBox) (типа Rect (прямоугольник); по умолчанию не задано или (0,0,0,0), т.е. никакого выравнивания не производится, и свойства растяжения и выравнивания игнорируются). Как описано выше в общих чертах со ссылкой на фиг.18-20, другие свойства включают в себя растяжение, которое, когда не задано, сохраняет исходный размер или может принимать значение 1) Fill, при котором форматное отношение не сохраняется, и контент масштабируется для заполнения границ, установленных посредством top/left/width/height (верх/лево/ширина/высота), 2) Uniform, предусматривающее однородное масштабирование, пока изображение не уместится в границах, установленных посредством top/left/width/height (верх/лево/ширина/высота), или 3) UniformToFill, предусматривающее однородное масштабирование для заполнения границ, установленных посредством top/left/width/height (верх/лево/ширина/высота), и, при необходимости, отсечения.
Для дальнейшей корреляции с низкоуровневой объектной моделью свойство трансформации устанавливает новую систему координат для потомков элемента, тогда как свойство «отсечение» ограничивает область, в пределах которой контент можно рисовать на холсте, причем путь отсечения по умолчанию задан как ограничивающее окно. Свойство ZIndex можно использовать для задания порядка визуализации вложенных элементов «холст» в панели.
Окно видимости (ViewBox) задает новую систему координат для контентов, например, переопределяя протяженность и начало отсчета окна просмотра (ViewPort). Растяжение помогает задавать, как эти контенты отображаются в окно просмотра. Значение атрибута ViewBox - это список из четырех «безразмерных» чисел <min-x>, <min-y>, <width> и <height>, например, разделенных пробелом и/или запятой, и относится к типу Rect. Значение типа Rect окна видимости задает прямоугольник в пользовательском пространстве, который отображается в ограничивающее окно. Оно действует так же, как вставка scaleX и scaleY. Свойство растяжения (в случае, когда опция отлична от none) обеспечивает дополнительное управление для сохранения форматного отношения графики. Дополнительная трансформация применяется к потомкам данного элемента для получения указанного эффекта.
В вышеприведенном примере эффективный результат прямоугольника в вышеприведенном образце разметки по каждому правилу растяжения будет иметь вид:
При наличии трансформации на холсте, оно, по существу, применяется над (например, в дереве) отображением в окно видимости. Заметим, что это отображение будет растягивать любые элементы на холсте, например окна, текст и т.д., но не формы. Далее, заметим, что если задано окно видимости, то холст уже не подгоняет свой размер к своим контентам, но имеет заданный размер. Если также заданы y-ширина и y-высота, то свойства растяжения/выравнивания используют, чтобы уместить окно видимости в заданные ширину и высоту.
К каждому элементу в объектной модели можно применять атрибут 'Clip' (отсечение). На некоторых элементах, особенно формах, это представляется непосредственно как общее свойство исполнения языка, тогда как на других (например, большинстве элементов управления) это свойство устанавливается через DinamicProperty (динамическое свойство).
В общем случае, путь отсечения ограничивает область, в пределах которой можно рисовать контент, что, в целом, представлено на фиг.27, где кнопка показана в необрезанном виде 2702 и в виде 2704, в котором задан путь отсечения (пунктирная линия представляет путь отсечения). В принципе, любые пути рисования, лежащие за пределами области, ограниченной активным в данный момент путем отсечения, не рисуются. Путь отсечения можно рассматривать как маску, в которой те пиксели, которые находятся вне пути отсечения, являются черными со значением альфа, равным нулю, а те пиксели, которые находятся внутри пути отсечения, являются белыми со значением альфа, равным единице (за возможным исключением сглаживания вдоль ребра силуэта).
Путь отсечения задают посредством объекта «геометрия» либо встроенным, либо, чаще, в секции ресурсов. Путь отсечения используют и/или ссылаются на него с использованием свойства "Clip" на элементе, что показано в нижеприведенном примере:
Заметим, что анимация свойства «отсечение» аналогична анимации трансформаций:
Путь рисуют, задавая данные «геометрии» и свойства визуализации, например, Fill (заливка), Stroke (обводка) и StrokeWidth (ширина обводки) на элементе Path (путь). Ниже приведен пример разметки для пути:
Строка «данные» пути относится к типу Geometry. Более развернутый и полный способ задания нарисованного пути предусматривает использование сложного синтаксиса свойств, который описан выше. Разметка (например, как в нижеприведенном примере) поступает непосредственно в описанные выше классы построителя геометрии:
Строку данных пути также описывают, используя следующую систему записи для описания грамматики строки данных пути:
Ниже показана информация строки данных пути, описанная с помощью этой системы записи (заметим, что в одной реализации здесь может быть задано FillMode вместо свойства на уровне элементов):
Элемент «изображение» (фиг.25) указывает, что контенты полного файла подлежат визуализации в данный прямоугольник в текущей пользовательской системе координат. Изображение (указанное тэгом изображения) может относится к файлам растрового изображения, например PNG или JPEG, или к файлам с типом MIME "image/wvg", что изложено в следующем примере:
В нижеследующей таблице представлена информация по некоторым иллюстративным свойствам для изображений:
Left (?),
Center (?),
Right (?)
}
Top (?),
Middle (?),
Bottom (?)
}
Fill,
Uniform,
UniformToFill
MetaDataReady,
Loading,
Loaded
LoadError
}
Согласно описанному выше формы соответствуют геометрии, нарисованной с помощью унаследованных и каскадированных свойств презентации. В нижеследующих таблицах приведен пример свойств формы для элементов основных форм, описанных выше (прямоугольник, эллипс, линия, полилиния, многоугольник). Заметим, что эти основные формы могут иметь свойства окантовки, свойства заливки и при использовании в качестве путей отсечения иметь характеристики наследования и применяться как к уровню элементов, так и к уровню ресурсов:
EvenOdd,
NonZero
}
Butt,
Round,
Square,
Diamond
}
Miter,
Round,
Bevel
}
Ниже приведен пример синтаксиса разметки для прямоугольника:
Прямоугольник имеет следующие свойства в объектной модели (заметим, что прямоугольники допускают чтение/запись, имеют значения по умолчанию, равные нулю, поддерживают наследование и применяются как к уровню элементов, так и к уровню объектов):
Ниже приведен пример синтаксиса разметки для круга:
Круг имеет следующие свойства в объектной модели (заметим, что круги допускают чтение/запись, имеют значения по умолчанию, равные нулю, поддерживают наследование и применяются как к уровню элементов, так и к уровню объектов):
Ниже приведен пример синтаксиса разметки для эллипса:
Эллипс имеет следующие свойства в объектной модели (заметим, что круги допускают чтение/запись, имеют значения по умолчанию, равные нулю, поддерживают наследование и применяются как к уровню элементов, так и к уровню объектов):
Ниже приведен пример синтаксиса разметки для линии:
Линия имеет следующие свойства в объектной модели (заметим, что линии допускают чтение/запись, имеют значения по умолчанию, равные нулю, поддерживают наследование и применяются как к уровню элементов, так и к уровню объектов):
'Poliline' (полилиния) задает набор соединенных прямолинейных отрезков. Обычно полилиния задает открытую форму.
Ниже приведен пример синтаксиса разметки для полилинии:
Полилиния имеет следующие свойства в объектной модели (заметим, что полилинии допускают чтение/запись, имеют значения по умолчанию, равные null, поддерживают наследование и применяются как к уровню элементов, так и к уровню объектов):
Элемент «многоугольник» задает замкнутую форму, содержащую набор соединенных прямолинейных отрезков. Ниже приведен пример синтаксиса разметки для прямоугольника:
Многоугольник имеет следующие свойства в объектной модели (заметим, что многоугольники допускают чтение/запись, имеют значения по умолчанию, равные null, поддерживают наследование и применяются как к уровню элементов, так и к уровню объектов):
Грамматика для задания точек в элементах «полилиния» и «многоугольник» описана с помощью следующей системы записи:
Ниже описано задание точек в элементах «полилиния» и «многоугольник» с использованием вышеприведенной системы записи:
Заключение
Как можно видеть из вышеприведенного подробного описания, предусмотрена система, способ и элементная/объектная модель, которая обеспечивает программный код различными механизмами взаимодействия с графом сцены. Система, способ и объектная модель просты в использовании, но отличаются мощностью, гибкостью и расширяемостью.
Хотя изобретение допускает различные модификации и альтернативные конструкции, определенные проиллюстрированные элементы его осуществления показаны на чертежах и были подробно описаны выше. Однако следует понимать, что раскрытые частные формы не призваны ограничивать изобретение, но, напротив, изобретение охватывает все модификации, альтернативные конструкции и эквиваленты, отвечающие сущности и объему изобретения.
| название | год | авторы | номер документа |
|---|---|---|---|
| УРОВЕНЬ ИНТЕГРАЦИИ СРЕД | 2004 |
|
RU2360275C2 |
| ВИЗУАЛЬНЫЙ И ПРОСТРАНСТВЕННЫЙ ГРАФИЧЕСКИЕ ИНТЕРФЕЙСЫ | 2003 |
|
RU2324229C2 |
| ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ДЛЯ КОМПЬЮТЕРНОЙ ПЛАТФОРМЫ | 2004 |
|
RU2371758C2 |
| ИНТЕГРАЦИЯ ИЕРАРХИИ ТРЕХМЕРНОЙ СЦЕНЫ В ДВУМЕРНУЮ СИСТЕМУ КОМПОНОВКИ ИЗОБРАЖЕНИЙ | 2004 |
|
RU2360290C2 |
| ИНТЕРФЕЙСЫ ВИЗУАЛЬНОГО ОБЪЕКТА И ГРАФА СЦЕНЫ | 2004 |
|
RU2363984C2 |
| МОДУЛЬНЫЙ ФОРМАТ ДОКУМЕНТОВ | 2004 |
|
RU2368943C2 |
| СИСТЕМА ДЛЯ ОБЕСПЕЧЕНИЯ ХОСТИНГА ОБЪЕКТОВ ГРАФИЧЕСКОЙ КОМПОНОВКИ/ПРЕДСТАВЛЕНИЯ | 2003 |
|
RU2305860C2 |
| КООРДИНАЦИЯ АНИМАЦИЙ И МУЛЬТИМЕДИА ПРИ ВЫВОДЕ НА КОМПЬЮТЕРНЫЙ ДИСПЛЕЙ | 2005 |
|
RU2391709C2 |
| СИСТЕМЫ И СПОСОБЫ СОПРЯЖЕНИЯ ПРИКЛАДНЫХ ПРОГРАММ С ПЛАТФОРМОЙ ХРАНЕНИЯ НА ОСНОВЕ СТАТЕЙ | 2003 |
|
RU2412461C2 |
| СИСТЕМЫ И СПОСОБЫ МОДЕЛИРОВАНИЯ ДАННЫХ В ОСНОВАННОЙ НА ПРЕДМЕТАХ ПЛАТФОРМЕ ХРАНЕНИЯ | 2003 |
|
RU2371757C2 |
Изобретение относится к вычислительной технике. Техническим результатом является обеспечение согласованного взаимодействия разработчиков компьютерной программы со структурой данных графа сцен для создания графики. Система содержит язык разметки, объектную модель графики, преобразователь типов, анализатор/транслятор, систему презентаторов, интерфейс прикладного программирования визуалов и интерфейс отображения. 26 з.п. ф-лы, 27 ил.
язык разметки, содержащий команды графики, причем команды графики содержат формат строки и представление объекта, при этом представление объекта содержит элементы графики из класса элементов графики;
объектную модель графики, содержащую класс элементов графики, причем класс элементов содержит класс формы, класс изображений, класс видео и класс холста, причем упомянутый класс элементов интегрирован с системой общих свойств;
преобразователь типов, выполненный с возможностью преобразовывать команды графики в формате строки в объект API визуалов,
анализатор/транслятор, причем
анализатор/транслятор выполнен с возможностью интерпретировать команды графики, причем команды графики содержат вызовы непосредственно кода, вызовы кода объектной модели, и при этом команды графики записаны с использованием упомянутого языка разметки; причем
анализатор/транслятор дополнительно выполнен с возможностью обращаться к преобразователю типов, который сконфигурирован преобразовывать команды графики в формате строки в объект API визуалов, причем
анализатор/транслятор дополнительно выполнен с возможностью интерпретировать код разметки и при интерпретации кода разметки добавлять элементы класса элементов графики к элементному дереву;
систему презентаторов, выполненную с возможностью транслировать элементные деревья графики в вызовы к интерфейсу прикладного программирования визуалов,
интерфейс прикладного программирования визуалов, выполненный с возможностью взаимодействия с системой презентаторов, взаимодействия с анализатором/транслятором, взаимодействия с вызовами непосредственно кода из языков программирования, причем
интерфейс прикладного программирования визуалов дополнительно выполнен с возможностью в ответ на запросы от системы презентаторов анализатора/транслятора создавать объекты в графе сцены, и
интерфейс отображения, выполненный с возможностью отображения графических объектов в графе сцены.
| US 6215495 B1, 10.04.2001 | |||
| УСТРОЙСТВО ДЛЯ СИСТЕМЫ РАСПРЕДЕЛЕНИЯ ТЕЛЕВИЗИОННЫХ ПРОГРАММ И СПОСОБ РАСПРЕДЕЛЕНИЯ ТЕЛЕВИЗИОННЫХ ПРОГРАММ В СИСТЕМЕ РАСПРЕДЕЛЕНИЯ ТЕЛЕВИЗИОННЫХ ПРОГРАММ | 1993 |
|
RU2138923C1 |
| Дорожная спиртовая кухня | 1918 |
|
SU98A1 |
| EP 1156429 A2, 21.11.2001 | |||
| Топчак-трактор для канатной вспашки | 1923 |
|
SU2002A1 |
| Аппарат для очищения воды при помощи химических реактивов | 1917 |
|
SU2A1 |
