ВИЗУАЛЬНЫЙ И ПРОСТРАНСТВЕННЫЙ ГРАФИЧЕСКИЕ ИНТЕРФЕЙСЫ

ССЫЛКИ НА РОДСТВЕННЫЕ ЗАЯВКИ

Данное изобретение относится к следующим находящимся в процессе одновременного рассмотрения патентным заявкам США: регистрационный номер 10/184795 с названием «Multiple-Level Graphics Processing System and Method»; регистрационный номер 10/184796 с названием «Generic Parametrization for a Scene Graph»; регистрационный номер 10/185775 с названием «Intelligent Caching Data Structure for Immediate Mode Graphics»; каждая зарегистрирована 27 июня 2002 г.; и патентная заявка США с названием «Markup Language and Object Model for Vector Graphics» (Досье поверенного № 3480), поданные одновременно. Каждая родственная заявка передана правопреемнику данной патентной заявки и включена здесь посредством ссылки в ее целостности.

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

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

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

Пределы традиционной модели непосредственного режима доступа к графике в компьютерных системах достигаются частично потому, что память и скорости шин не поддерживаются в соответствии с улучшениями в основных процессорах и/или графических процессорах. В общем, текущая (например, WM_PAINT) модель для подготовки кадра требует слишком большой обработки данных для поддержания частоты регенерации аппаратного обеспечения, когда требуются сложные графические эффекты. В результате, когда сложные графические эффекты применяются со стандартными графическими моделями, вместо завершения изменений, которые приводят к воспринимаемым визуальным эффектам своевременно для следующего кадра, изменения могут добавляться на других кадрах, что вызывает результаты, которые визуально и заметно не желательны.

Новая модель для управления выводом графики описана в вышеупомянутых патентных заявках США с номерами 10/184795, 10/184796 и 10/185775. Эта новая модель обеспечивает множество значительных улучшений в технологии обработки графики. Например, заявка № 10/184795 США по существу направлена на способ и систему многоуровневой обработки графики, в котором компонента более высокого уровня (например, операционной системы) выполняет вычислительно интенсивные аспекты построения графа сцены (визуализируемого трехмерного пространства), обновления параметров мультипликации и обхода структур данных графа сцены, при относительно низкой скорости работы, для прохождения упрощенных структур данных и/или команд графики к компоненту низкого уровня. Поскольку высокоуровневая обработка сильно упрощает данные, компонент низкого уровня может работать при более высокой скорости (относительно высокоуровневого компонента), такой как скорость, которая соответствует частоте регенерации кадров в графической подсистеме, для обработки данных в постоянные выходные данные для графической подсистемы. При использовании мультипликации вместо повторной перерисовки всей сцены с изменениями низкоуровневая обработка может интерполировать интервалы параметров, необходимые для получения мгновенных величин, которые при визуализации обеспечивают слегка измененную сцену для каждого кадра, обеспечивая мультипликацию с плавными переходами между кадрами.

Заявка US № 10/184796 описывает параметризованный граф сцены, который обеспечивает изменчивые ("оживленные") величины и параметризованные контейнеры (накопители) графа таким образом, что программный код, который желает рисовать графику (например, прикладная программа или компонент операционной системы), может избирательно изменять некоторые аспекты описания графа сцены, оставляя другие аспекты неповрежденными. Программный код может также повторно использовать уже построенные части графа сцены, возможно с другими параметрами. Как может быть оценено, способность легко изменять внешний вид отображаемых элементов через параметризацию и/или повторное использование существующих частей графа сцены обеспечивает существенный выигрыш в общей эффективности обработки графики.

Заявка № 10/185775 по существу описывает структуру данных с кэшированием и связанные механизмы для сохранения визуальной информации через объекты и данные в графе сцены. Структура данных обычно связана с механизмами, которые интеллектуально управляют, как визуальная информация в них заполняется и используется. Например, если нет конкретного запроса прикладной программой, большая часть информации, хранимой в структуре данных, не имеет внешней ссылки на нее, что дает возможность данной информации быть оптимизированной или обработанной другим образом. Как может быть оценено, это обеспечивает эффективность и сохранение ресурсов, например, данные в структуре данных с кэшированием могут быть обработаны в другой формат, который является более компактным и/или уменьшает необходимость в последующей, повторной обработке, такой как растр или другой результат после обработки.

Хотя вышеуказанные усовершенствования обеспечивают существенные выгоды в технологии обработки графики, все же есть необходимость в способе для программ для эффективного использования этой усовершенствованной модели графики и в других связанных усовершенствованиях непосредственным образом. Необходим комплексный и все же непосредственный способ для программ воспользоваться многими особенностями и способностями обработки графики, обеспеченными усовершенствованной моделью графики, и тем самым выдавать сложную графику эффективным способом.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Вкратце, данное изобретение обеспечивает модель объекта и программный интерфейс приложения (API) для доступа к этой модели объекта способом, который позволяет разработчикам кода программ согласованно взаимодействовать со структурой данных графа сцены для создания графики. Базовым объектом в модели и множестве API является «визуал», который представляет виртуальную поверхность для пользователя; граф сцены построен из объектов визуала. Такие Визуалы включают в себя визуальные объекты контейнера, визуальные объекты проверки правильности, визуальные объекты рисования и визуальные объекты поверхности. Сами Визуалы могут удерживаться на ресурсных объектах, таких как объекты отсечения, объектах преобразования и т.д., а некоторые типы Визуалов (например, DrawingVisual - Визуал рисования, ValidationVisual - Визуал проверки правильности) могут удерживаться на списках команд рисования, которые могут ссылаться на ресурсные объекты, такие как изображения, кисти и/или градиенты.

Типичные ресурсные объекты в графе сцены являются неизменными после создания, а именно после их создания они не могут быть изменены. Отметим, что визуалы обычно не считаются ресурсами и что визуалы не считаются неизменными в некоторой степени, например, код программы может заменить преобразование, на которое указывает Визуал, но не может изменить само преобразование, так как преобразование является неизменным. Объекты могут быть определены конструктором или путем использования сопутствующего объекта-"строителя".

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

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

Визуалы контейнера предусматривают коллекцию дочерних визуалов и в одном варианте осуществления являются единственными визуалами, которые могут определить иерархию. Коллекция потомков на визуале контейнера учитывает произвольную вставку, удаление и переупорядочение дочерних визуалов.

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

Визуал проверки правильности работает подобным же образом, что и визуал рисования, за исключением того, что его контекст рисования заполняется, когда система требует, чтобы он был заполнен, а не когда код программы желает заполнить его. Визуал поверхности обеспечен для показа растра данных элемента изображения, который может соответствовать контексту рисования, заполненному данными элементов изображения, или другому подграфу визуала, через который проходит диспетчер визуала поверхности, который обеспечивает данные элемента изображения. Система обеспечивает реализацию контекста рисования, которая может непосредственно рисовать в поверхность, и SurfaceVisualManager (диспетчер визуала поверхности) может использоваться для составления графа сцены Визуала в поверхность. Другие типы визуалов также описываются.

Таким образом, различные типы примитивов могут быть нарисованы в визуал с использованием контекста рисования, включая данные геометрии, данные изображения и видеоданные. Геометрия является типом класса, который определяет заготовку векторной графики без штриховки или заполнения, например прямоугольник. Каждый объект геометрии соответствует простой форме (LineGeometry - геометрия линии, EllipseGeometry - геометрия эллипса, RectangleGeometry - геометрия прямоугольника), сложной единственной форме (PathGeometry - геометрия пути) или списку таких форм (GeometryList - список геометрии) с определенной комбинированной операцией (например, объединение, пересечение и т.д.). Эти объекты образуют иерархию классов. Также имеются клавиши быстрого вызова для рисования часто используемых типов геометрии, таких как способ DrawRectangle (нарисовать прямоугольник). Когда геометрия рисуется, может быть определена кисть или перо. Объект кисти определяет, как графически заполнить плоскость, и имеется иерархия классов объектов кисти. Перо также имеет кисть, определенную на нем, описывающую, как заполнить штриховую область. Специальный тип объекта кисти (VisualBrush - визуальная кисть) может ссылаться на визуал для определения, как эта кисть должна быть нарисована.

Другие выгоды и преимущества явствуют из следующего подробного описания, взятого в сочетании с чертежами.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фигура 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 - представление классов преобразования модели объекта в соответствии с аспектом данного изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

ПРИМЕРНОЕ РАБОЧЕЕ ОКРУЖЕНИЕ

Фигура 1 показывает пример подходящей среды 100 вычислительной системы, в которой может быть реализовано изобретение. Среда 100 компьютерной системы является только одним примером подходящего вычислительного окружения и не предназначено для предложения какого-либо ограничения объема использования или функциональности изобретения. Также вычислительная среда 100 не должна интерпретироваться как имеющая какую-либо зависимость или требование, касающееся любого компонента или комбинации компонентов, показанных в примерном рабочем окружении 100.

Изобретение работает с многочисленными другими окружениями или конфигурациями вычислительной системы общего или специального назначения. Примеры хорошо известных вычислительных систем, окружений и/или конфигураций, которые могут быть подходящими для использования с изобретением, включают в себя, но не ограничены, персональные компьютеры, компьютеры-серверы, карманные или портативные устройства, устройства с графическим планшетом, мультипроцессорные системы, основанные на микропроцессорах системы, телеприставки, программируемая потребительская электроника, сетевые ПК, миникомпьютеры, большие ЭВМ, распределенные вычислительные окружения, которые включают в себя любые из вышеупомянутых систем или устройств, и т.п.

Изобретение может быть описано в общем контексте выполняемых компьютером команд, таких как программные модули, выполняемые компьютером. В общем, программные модули включают в себя подпрограммы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют особые задачи или реализуют особые абстрактные типы данных. Изобретение может быть также реализовано в распределенных вычислительных средах, где задачи выполняются удаленными обрабатывающими устройствами, которые подсоединены через сеть связи. В распределенном вычислительном устройстве программные модули могут быть расположены как в локальных, так и в удаленных компьютерных носителях данных, включающих запоминающие устройства.

Со ссылкой на фиг. 1 примерная система для реализации изобретения включает в себя вычислительное устройство общего назначения в форме компьютера 110. Компоненты компьютера 110 могут включать в себя, но не ограничены, процессор 120, системную память 130 и системную шину 121, которая связывает различные системные компоненты, включая системную память, с процессором 120. Системная шина 121 может быть любой из нескольких типов структур шин, включающих в себя шину памяти или контроллер памяти, шину периферийных устройств и локальную шину, использующие любую из разнообразия архитектур шин. Посредством примера, а не ограничения, такие архитектуры включают в себя шину промышленной стандартной архитектуры (ISA), шину микроканальной архитектуры (МСА), шину расширенной промышленной стандартной архитектуры (EISA), локальную шину Ассоциации по стандартам видеооборудования (видеоэлектроники) (VESA), шину ускоренного графического порта (AGP) и шину межсоединения периферийных компонентов (PCI), известную также как шина расширения.

Компьютер 110 обычно включает в себя множество считываемых компьютером носителей. Считываемыми компьютером носителями могут быть любые доступные носители, которые могут быть доступны компьютеру 110 и включают в себя как энергозависимые, так и энергонезависимые носители, и удаляемые и неудаляемые носители. Посредством примера, а не ограничения, считываемый компьютером носитель может содержать компьютерный носитель данных и среду передачи данных. Компьютерный носитель данных включает в себя как энергозависимые и энергонезависимые, сменные и несменные носители, реализованные в любом способе или технологии для сохранения информации, такой как считываемые компьютером команды, структуры данных, программные модули и другие данные. Компьютерный носитель данных включает в себя, но не ограничен этим, ОЗУ, ПЗУ, ЭСППЗУ, флэш-память или другую технологию памяти, ПЗУ на компакт-диске (CD-ROM), цифровые универсальные диски (DVD) или другую память на оптических дисках, магнитные кассеты, магнитная лента, память на магнитных дисках или другие магнитные запоминающие устройства, или любой другой носитель, который может быть использован для сохранения желаемой информации, и который может быть доступен компьютеру 110. Среда передачи данных обычно заключает в себе считываемые компьютером команды, структуры данных, программные модули или другие данные в модулированном сигнале передачи данных, таком как несущая или другой механизм переноса, и включает в себя любую среду распространения информации. Термин «модулированный сигнал передачи данных» означает сигнал, который имеет одну или несколько своих характеристик, установленных или измененных таким образом, чтобы закодировать информацию в этом сигнале. Посредством примера, а не ограничения, среда передачи данных включает в себя проводные носители, такие как проводная сеть или соединение прямым проводом, и беспроводные среды, такие как акустическая, радиочастотная, инфракрасная и другие беспроводные среды. Комбинации любого из вышеупомянутого следует также включить в объем считываемого компьютером носителя.

Системная память 130 включает в себя компьютерный носитель данных в форме энергозависимой и/или энергонезависимой памяти, такой как ПЗУ (ROM) 131 и ОЗУ (RAM) 132. Базовая система ввода/вывода 133 (BIOS), содержащая базовые подпрограммы, которые помогают передавать информацию между элементами в компьютере 110, например, во время запуска, обычно хранится в ПЗУ 131. ОЗУ 132 обычно содержит данные и/или программные модули, которые немедленно доступны и/или управляются в данный момент процессором 120. Посредством примера, а не ограничения, фиг. 1 показывает операционную систему 134, прикладные программы 135, другие программные модули 136 и программные данные 137.

Компьютер 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, других программных модулей 136 и программных данных 137. Операционной системе 144, прикладным программам 145, другим программным модулям 146 и программным данным 147 даны здесь другие номера для иллюстрации того, что они, как минимум, являются различными копиями. Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, такие как графический планшет (электронное устройство ввода графической информации) 164, микрофон 163, клавиатура 162 и указывающее устройство 161, обычно называемое мышью, шаровым указателем (трекболом) или сенсорным планшетом. Другие устройства ввода (не показано) могут включать в себя джойстик, игровую панель, спутниковую тарелку, сканер и т.п. Эти и другие устройства ввода часто подключены к процессору 120 через интерфейс 160 ввода пользователя, который подключен к системной шине, но может быть подключен другими интерфейсом и структурами шин, такими как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 191 или другой тип устройства отображения также подключен к системной шине 121 через интерфейс, такой как видеоинтерфейс 190. Монитор 191 может также быть интегрированным с панелью 193 сенсорного экрана и т.п., которая может вводить оцифрованный ввод, такой как рукописный текст в компьютерную систему 110 через интерфейс, такой как интерфейс 190 сенсорного экрана. Отметим, что монитор и/или панель сенсорного экрана может быть физически связан с корпусом, в который заключено вычислительное устройство 110, как, например, в персональном компьютере типа графического планшета, в котором панель 193 сенсорного экрана по существу служит как графический планшет 164. Кроме того, компьютеры, такие как вычислительное устройство 110, могут также включать в себя другие периферийные устройства вывода, такие как громкоговорители 195 и принтер 196, которые могут быть подключены через интерфейс 194 периферийных устройств вывода и т.п.

Компьютер 110 может работать в сетевом окружении с использованием логических соединений с одним или несколькими удаленными компьютерами, такими как удаленный компьютер 180. Удаленный компьютер 180 может быть персональным компьютером, сервером, маршрутизатором, сетевым ПК, равноправным устройством или другим узлом общей сети, и обычно включает в себя многие или все элементы, описанные выше относительно компьютера 110, хотя на фиг. 1 показано только запоминающее устройство 181. Логические соединения, изображенные на фиг. 1, включают в себя локальную вычислительную сеть (LAN) 171 и глобальную сеть (WAN) 173, но также могут включать в себя другие сети. Такие сетевые окружения являются обычными в офисах, компьютерных сетях масштаба предприятия, интранет и Интернет.

При использовании в сетевом окружении LAN, компьютер 110 подключен к LAN 171 через сетевой интерфейс или адаптер 170. При использовании в сетевом окружении WAN, компьютер 110 обычно включает в себя модем 172 или другое средство для установления связи по WAN 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, может быть подключен к системной шине 121 через интерфейс 160 ввода пользователя или другой соответствующий механизм. В сетевом окружении программные модули, изображенные относительно компьютера 110, или его частей, могут сохраняться в удаленном запоминающем устройстве. Посредством примера, а не ограничения, фиг. 1 показывает удаленные прикладные программы 185, остающиеся в запоминающем устройстве 181. Будет оценено, что показанные сетевые соединения являются примерными и что могут быть использованы и другие средства для установления линии связи между компьютерами.

ИНТЕРФЕЙСЫ К СТРУКТУРАМ ДАННЫХ ГРАФА СЦЕНЫ

Один аспект данного изобретения по существу направлен на то, чтобы позволить программному коду, такому как приложение или компонент операционной системы, связывать команды рисования и другую информацию (например, растры изображений) с компонентами графики для визуализации графического вывода на системном дисплее. Для этой цели данное изобретение обеспечивает большое количество определенных функций и способов, например, в форме программных интерфейсов приложений (API) для модели объекта, которая позволяет программам заполнять граф сцены структурами данных, графическими примитивами (командами) и другими связанными с графикой данными. При обработке граф сцены приводит к графике (графическому изображению), отображаемой на экране.

Фиг. 2 представляет общую, многоуровневую архитектуру 200, в которой может быть реализовано данное изобретение. Как представлено на фиг. 2, код 202 программы (например, прикладной программы или компонента операционной системы) может быть развит в данные выходного графического изображения одним или несколькими различными способами, в том числе через формирование изображения 204, через элементы 206 векторной графики и/или через вызовы функции/способа, накладываемые непосредственно на уровень 212 визуального программного интерфейса приложений (API), в соответствии с аспектом данного изобретения. В общем, формирование изображения 204 обеспечивает код 202 программы механизмом для загрузки, редактирования и сохранения изображений, например, растров. Как описано ниже, эти изображения могут использоваться другими частями системы, и также существует способ использования кода рисования примитивов для непосредственного рисования изображения. Элементы 206 векторной графики обеспечивают другой способ рисования графики (графического изображения), совместимый с остальной частью модели объекта (описанной ниже). Элементы 206 векторной графики могут быть созданы через язык разметки, который система 208 элемента/свойства и система 210 предъявителя интерпретируют для того, чтобы сделать соответствующие вызовы в визуальный уровень 212 API. Элементы 206 векторной графики, вместе с системой 208 элемента/свойства и системой 210 предъявителя, описаны в вышеупомянутой находящейся в процессе одновременного рассмотрения патентной заявке с названием «Markup Language and Object Model for Vector Graphics».

В одной реализации архитектура 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 формирования изображения осуществить требующую значительного времени или специфическую для приложения визуализацию на более высоких уровнях, и прохождения ссылок на растр к более низким уровням.

Фиг. 3 и 4 показывают примерные графы сцены 300 и 400 соответственно, включающие базовый объект, называемый визуалом. В общем, визуал содержит объект, который представляет виртуальную поверхность пользователю и имеет визуальное представление на дисплее. Как представлено на фиг. 5, визуал базового класса обеспечивает базовую функциональность (функциональные возможности) для других типов визуала, а именно визуальный класс 500 является абстрактным базовым классом, от которого происходят визуальные типы (например, 501-506).

Как представлено на фиг. 3, визуал верхнего уровня (или корневой визуал) 302 соединен с объектом 302 диспетчера визуала, который также имеет связь (например, через идентификатор) с окном (Hwnd) 306 или подобным блоком, в которое графические данные выводятся для кода программы. VisualManager (диспетчер визуала) 304 управляет рисованием визуала верхнего уровня (и любых потомков этого визуала) в это окно 306. Фиг. 6 показывает VisualManager как один из множества других объектов 620 в модели объекта описываемой здесь графической системы.

Для рисования, диспетчер 304 визуала обрабатывает (например, проходит или передает) граф сцены, как запланировано диспетчером 308, и обеспечивает команды графики и другие данные компоненту 218 низкого уровня (фиг. 2) для его соответствующего окна 306, как в сущности описано в патентных заявках США с регистрационными номерами 10/184795, 10/184796 и 10/185775. Обработка графа сцены будет как правило планироваться диспетчером 308 при скорости, которая относительно более медленная, чем частота регенерации низкоуровневого компонента 218 и/или подсистемы 222 графики. Фиг. 3 показывает большое число дочерних визуалов 310-315, расположенных иерархически ниже визуала 302 верхнего уровня (корневого визуала), некоторые из которых представлены как заполненные контекстами 316, 317 рисования (показанные как пунктирные прямоугольники для представления их временной природы) со связанными списками 318 и 319 команд, соответственно, например, содержащими графические примитивы и другие визуалы. Визуалы могут также содержать другую информацию о свойствах, как показано в следующем примерном классе визуала:

Как можно видеть, визуалы предлагают обслуживание (услуги) посредством обеспечения transform (преобразования), clip (отсечения), opacity (непрозрачности) и возможно других свойств, которые могут быть установлены и/или считаны через метод «get». Кроме того, визуал имеет флажки, управляющие тем, как он участвует в тестировании обращения, как описано ниже. Свойство Show используется для показа/сокрытия визуала, например, когда имеется значение "ложь", визуал является невидимым, в противном случае визуал является видимым.

Преобразование, установленное свойством transform, определяет систему координат для подграфа визуала. Система координат перед преобразованием называется системой координат pre-transform, система координат после преобразования называется системой координат post-transform, а именно визуал с преобразованием эквивалентен визуалу с узлом преобразования в качестве родителя. Фиг. 7 по существу обеспечивает пример преобразования, идентифицирующий системы координат pre-transformation и post-transformation относительно визуала. Чтобы получить (get) или установить (set) преобразование визуала, может быть использовано свойство Transform.

Отметим, что координатные преобразования могут применяться однородным образом ко всему, как будто бы это было в растре. Отметим, что это не означает, что преобразования всегда применяются к растрам, но что преобразования равным образом влияют на то, что визуализировали методы gets. Посредством примера, если пользователь рисует окружность круглым пером, которое имеет ширину в один дюйм, а затем применяет масштаб в направлении оси Х в два раза больше, чем эта окружность, то перо будет иметь два дюйма в ширину влево и вправо и только один дюйм в ширину вверх и вниз. Это иногда называется композицией или преобразованием растра (в противоположность заготовке или геометрической шкале, которая влияет только на геометрию). Фиг. 8А является представлением преобразования масштабирования с непреобразованным изображением 800, появляющимся слева, и преобразованным изображением 802 с неоднородным масштабом, появляющимся справа. Фиг. 8В является представлением преобразования масштабирования с непреобразованным изображением 800 слева и преобразованным изображением 804 с геометрическим масштабированием справа.

Относительно координатного преобразования визуала, TransformToDescendant преобразует точку от опорного визуала к визуалу узла-потомка. Точка преобразуется из координатного пространства опорного визуала после преобразования в координатное пространство визуала узла-потомка после преобразования. TransformFromDescendant преобразует точку из визуала узла-потомка вверх по родительской цепочке к опорному визуалу. Точка преобразуется из координатного пространства визуала узла-потомка после преобразования в координатное пространство опорного визуала после преобразования. Метод CalculateBounds (вычислить границы) возвращает ограничивающий прямоугольник содержимого Визуала в координатном пространстве после преобразования. Отметим, что может быть альтернативная версия API, где разрешены более конкретные спецификации того, как преобразование визуала интерпретируется во время преобразования координат. Например, преобразование опорного визуала и визуала-потомка может приниматься или может не приниматься во внимание. В этой альтернативе имеется, таким образом, четыре опции, например, координаты могут преобразовываться из пространства перед преобразованием в пространство перед преобразованием, из пространства перед преобразованием в пространство после преобразования, из пространства после преобразования в пространство перед преобразованием, и из пространства после преобразования в пространство после преобразования. Подобная же концепция применима к тестированию обращения, например, тестирование обращения может быть начато в пространстве преобразования координат до преобразования или после преобразования, и результаты теста обращения могут быть в координатном пространстве перед преобразованием или после преобразования.

Свойство отсечения (clip) устанавливает (sets) (и получает - gets) область отсечения визуала. Любая геометрия (Geometry) (класс геометрии описан ниже со ссылкой на фиг. 12) может быть использована как область отсечения, и область отсечения применяется в пространстве координат после преобразования. В одном варианте реализации установка по умолчанию для области отсечения есть нуль (пусто), т.е. нет отсечения, что представляется как бесконечно большой прямоугольник отсечения от (-∞, -∞) до (+∞, +∞).

Свойство Opacity получает/устанавливает (gets/sets) величину непрозрачности визуала, таким образом, что содержимое визуала усредняется на поверхности иллюстрации на основе величины непрозрачности и выбранного режима усреднения. Свойство BlendMode (режим усреднения) может быть использовано для установки (или получения) режима усреднения, который используется. Например, величина непрозрачности (alpha) может быть установлена между 0,0 и 1,0, с линейным alpha-усреднением, установленным как режим, например, Цвет = alpha*цвет переднего плана + (1,0-alpha)*цвет фона. В визуал могут быть включены и другие услуги, как, например, свойства специальных эффектов, например размывка, монохромность и т.д.

Различные услуги (включая преобразование, непрозрачность, отсечение) могут продвигаться (задаваться) и проталкиваться (вызываться) на контексте рисования, и могут быть вложены операции продвижения/проталкивания (задания/вызова), пока вызов проталкивания совпадает с вызовом продвижения. Например, 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();.

Отметим, что операции продвижения (задания) могут быть произвольно вложены, пока операции проталкивания (вызова) согласуются с продвижением (заданием). Например, следующее является допустимым:

Тестирование обращения (выбора) (hit-testing) осуществляется в координатном пространстве после преобразования и возвращает идентичность каждого тестируемого на обращение визуала, к которому обращаются (выбирают), например, при детектировании щелчка мышью или пером. Другая версия интерфейса может учитывать тестирование обращения для запуска в координатном пространстве перед преобразованием относительно визуала, где запущен тест обращения. Визуалы, которые выбраны (к которым было обращение), возвращаются в порядке слева направо, с первым уровнем глубины. Тестирование обращения может управляться различными флажками, включая HitTestable, который определяет, является ли визуал тестируемым на обращение (по умолчанию это верно), и HitTestFinal, который определяет, останавливается ли тестирование обращения, когда визуал является выбранным, т.е. если Визуал является выбранным и свойство HitTestFinal визуала является истинным, тестирование аварийно завершается и возвращает результаты, собранные до этого момента (по умолчанию это является ложным). Другим флажком является HitTestIgnoreChildren, который определяет, следует ли рассматривать потомков визуала, когда на визуале осуществляется тестирование обращения (по умолчанию это является ложным).

ProxyVisual является визуалом, который может быть добавлен более чем один раз в граф сцены. Поскольку любой визуал, на который ссылается ProxyVisual, может быть достигнут множественными путями от корня, услуги считывания (TransformToDescendent, TransformFromDescendent и HitTest) не работают через ProxyVisual. В сущности, имеется один канонический путь от любого визуала к корню дерева визуалов, и этот путь не включает в себя каких-либо ProxyVisuals.

Как представлено на фиг. 5, различные типы визуалов определены в модели объекта, включая ContainerVisuals (визуалы контейнера) 501, DrawingVisuals (визуалы рисования) 502, ValidationVisuals (визуалы проверки правильности) 503, SurfaceVisuals (визуалы поверхности) 504 и HwndVisuals 505. Таблица внизу излагает примерные способы DrawingVisual:

DrawingVisual является контейнером для графического содержания (например, линий, текста, изображений и т.д.). Отметим, что можно добавить Визуал в DrawingVisual, но в некоторых реализациях это не разрешено. DrawingVisual 502 включает в себя метод Open (открыть), который возвращает IDrawingContext, который может использоваться для заполнения DrawingVisual, например, другими визуалами и графическими примитивами, как описано ниже. В одной реализации, по различным причинам, также описанным ниже, DrawingVisual может быть только открыт один раз для заполнения своего контекста рисования; другими словами, такой DrawingVisual является неизменным по отношению к тому, что может быть помещено в него (хотя код программы может заменить объект ресурса, на который указывает визуал). После заполнения DrawingVisual, DrawingVisual закрывается с использованием метода Close (закрыть), например, на контексте рисования. Отметим, что вызов Open может очистить любое содержимое (потомков) визуала, однако в одной альтернативной реализации обеспечен метод Append (присоединить) для открытия текущего визуала способом, который присоединяет к этому визуалу. Другими словами, вызов OpenForAppend работает как Open, за исключением того, что текущее содержимое DrawingVisual не очищается на открытом.

Ниже представлен пример того, как контекст иллюстрации используется для заполнения визуала:

Обычно, ValidationVisual 503 концептуально подобен DrawingVisual, за исключением того, что ValidationVisual заполняется, когда система требует, чтобы он был заполненным, вместо того, когда код программы желает заполнить его. Например, как описано в заявке США 10/185775, механизм 214 композиции и мультипликации высокого уровня (фиг. 2) может делать недействительными данные графа сцены, так как необходимы ресурсы, например, когда часть графа сцены не является видимой. Например, если некоторые части прокручены (считаны) с дисплея, отсечены и т.д. Если сделанные недействительными данные графа сцены необходимы позднее, вызванный код 202 программы будет вызван снова для повторного рисования (проверки правильности) недействительной части графа сцены. С этой целью одним типичным сценарием использования для кода программы является подразбиение ValidationVisual и замена метода OnValidate. Когда система вызывает метод OnValidate, контекст рисования пропускается, и программа, которая использует контекст рисования, повторно заполняет ValidationVisual.

Пример внизу показывает один способ для реализации простого ValidationVisual, например, который рисует линию определенного цвета. Цвет линии может быть изменен путем вызова SetColor. Чтобы форсировать обновление ValidationVisual, SetColor вызывает Invalidate для того, чтобы заставить подсистему графики повторно проверить правильность ValidationVisual:

Этот пример показывает, как использовать ValidationVisual:

Фиг. 4 показывает примерный граф сцены 400, в котором ContainerVisuals и DrawingVisuals связаны в граф сцены и имеют связанные данные в форме графических примитивов (например, в соответствующих контекстах рисования). ContainerVisual является контейнером (накопителем) для Визуалов, и ContainerVisuals могут быть вложены друг в друга. Потомками ContainerVisuals можно манипулировать VisualCollection, возвращаемой из свойства Children в VisualContainer. Порядок Визуалов в VisualCollection определяет, в каком порядке визуализируются Визуалы, т.е. Визуалы визуализируются от самого нижнего индекса до самого высокого индекса от заднего к передним (порядок рисования). Например, с правильными параметрами с тремя визуалами рисования, представляющими красный, зеленый и синий прямоугольники иерархически под визуалом контейнера, следующий код привел бы к рисованию трех прямоугольников (смещенных вправо и вниз), красный прямоугольник сзади, зеленый прямоугольник в середине и синий прямоугольник спереди:

Как представлено на фиг. 5, другим типом визуального объекта является SurfaceVisual 504. Обычно, как представлено на фиг. 3, объект 315 SurfaceVisual ссылается на поверхность оперативной памяти (растр) 322, которой может достичь код 202 программы (фиг. 2). Код 202 программы клиента может поставлять свою собственную память поверхности, или он может требовать, чтобы память была назначена объектом поверхности.

Код 202 программы имеет опцию для открытия SurfaceVisual и получения контекста 323 рисования, в который код 202 программы может записать данные 324 элементов изображения или подобную информацию и непосредственно поместить эти пикселы на поверхность. Это представлено на фиг. 3 пунктирной линией между объектом 322 поверхности, контекстом 323 рисования (показанным как пунктирный прямоугольник для представления его временной природы) и данными 324 элемента изображения.

Код 202 программы также имеет опцию для создания диспетчера 330 визуалов поверхности и связывания подграфа 332 визуалов с SurfaceVisual 315. Эта опция представлена на фиг. 3 пунктирной линией между объектом 322 поверхности и диспетчером 330 визуалов поверхности. Отметим, что подграф 332 визуалов может также вкладывать другие визуалы поверхности, как также показано на фиг. 3. Диспетчер 330 визуалов поверхности (также показанный как тип другого объекта в множестве 620 фиг. 6) обходит подграф 332 визуалов для обновления растра 322 SurfaceVisual. Далее, отметим, что это прохождение запланировано диспетчером 308 и для эффективности может быть сужено для контроля того, как часто обновляется этот растр 322. Диспетчер 330 визуалов поверхности не должен проходить подграф 322 визуалов каждый раз и/или с той же скоростью, с которой диспетчер 302 визуалов верхнего уровня обходит остальную часть графа сцены.

По отношению к поверхностям, как далее описано со ссылкой на фиг. 9А-9С, как правило, данная модель графики, таким образом, позволяет компоновать множество визуалов к поверхности, в непосредственном режиме визуализировать векторные и растровые примитивы в поверхность, компоновать поверхность на панель экрана или на другую поверхность и контролировать, какая поверхность в списке поверхностей используется для составления в нее или рисования в ней. Список поверхностей определяется как собрание одной или нескольких поверхностей (т.е. кадры/буферы) физической (системной или видео) памяти, используемой для сохранения композиций визуалов или графических иллюстраций, или и того, и другого. Одна из поверхностей списка поверхностей может быть установлена как текущий задний буфер, где осуществляется рисование и/или компоновка, и одна из поверхностей списка поверхностей установлена как текущий первичный, или передний буфер, который используется для компоновки на другую цель визуализации.

Поверхности могут использоваться многочисленными способами. Посредством примера фиг. 9А показывает компоновку на поверхность. На фиг. 9А объект 900 диспетчера визуалов поверхности соединяет список 902 поверхностей как цель визуализации для дерева 904 визуалов. Во время каждого цикла компоновки визуалы компонуются в поверхность списка поверхностей, которая в данный момент служит в качестве активного заднего буфера для списка поверхностей. Поверхность, в которую компонуют, может включать в себя поверхность, принадлежащую клиенту/механизму 214 композиции (компоновки) высокого уровня (фиг. 2), для обрабатываемых сценариев компоновки, поверхность, принадлежащую механизму 218 компоновки низкого уровня для сценариев, где клиент не нуждается в битах, но механизм 218 компоновки низкого уровня нуждается в них для компоновки поверхности на другой цели визуализации, или поверхность перекрестных процессов, для сценариев, где клиент нуждается в доступе к битам поверхности, но механизм 218 компоновки низкого уровня также нуждается в поверхности для другой работы по компоновке.

Компоновка контролируется услугой синхронизации, которая присоединена к диспетчеру визуалов. Одним примером услуги синхронизации является ручной режим, который может быть использован, как в примере внизу:

Другим способом использования поверхности является визуализация непосредственного режима на поверхность, через контекст. Присоединение списка поверхностей к визуалу (визуалу поверхности) дает возможность визуализации в непосредственном режиме на поверхность из списка поверхностей, которая в данное время служит в качестве активного заднего буфера для списка поверхностей. Эта визуализация осуществляется путем получения контекста рисования из визуала поверхности и выполнения команд рисования на этом контексте, как описано выше. Отметим, что получение контекста рисования блокирует поверхность, так что другие операции компоновки не могут быть сделаны с ней. Каждая команда рисования выполняется немедленно, и векторы и другие поверхности могут быть нарисованы (смешаны) на этой поверхности. Однако другие визуалы не могут быть нарисованы на этой поверхности, но вместо этого могут быть составлены в поверхность путем связывания их с диспетчером визуалов, как описано выше (например, на фиг. 9А).

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

Реальная компоновка на поверхность/от поверхности представлена на фиг. 9С, где вышеописанные возможности сочетаются так, что компоновка на поверхность заднего буфера из списка поверхностей и компоновка от поверхности переднего буфера из списка поверхностей (например, на панель экрана) происходит одновременно. Отметим, что для устранения нежелательного видеоэффекта, известного как разрывание, список поверхностей должен иметь по меньшей мере две поверхности, поверхности переднего и заднего буфера. Поверхность, используемая как на фиг. 9С, вероятно принадлежит механизму 218 низкого уровня, или является поверхностью перекрестной обработки для того, чтобы лучше осуществить компоновку в механизме 218 низкого уровня.

Поверхности конструируются как независимые объекты, как изложено в примерах конструкторов ниже:

После конструирования, поверхность и/или список поверхностей может быть присоединен к объекту визуала поверхности или к объекту диспетчера визуалов.

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

Если вернуться к фиг. 5, то еще одним визуалом является HwndVisual 505, который помещает Win32 потомок HWnd в графе сцены. Более конкретно, традиционные программы будут все же работать через метод WM_PAINT (или подобный ему), который рисует до потомка HWnd (или подобного ему) на основе известной технологии графики. Для поддержки таких программ в новой модели обработки графики, HwndVisual позволяет Hwnd содержаться в графе сцены и перемещаться, как перемещается родительский визуал, как представлено на фиг. 10А. В результате ограничений с существующими Hwnd, однако, при визуализации потомок Hwnd может только быть наверху других окон, и не может быть вращаемым или масштабируемым, подобно другим описанным выше визуалам. Некоторое отсечение возможно, как представлено на фиг. 10В, где пунктирные линии указывают отображаемый прямоугольник Hwnd, отсеченный во время относительного движения по отношению к его родительскому визуалу.

Другие типы визуалов 506 также возможны, и данная модель объекта является растяжимой для того, чтобы позволить разработать другие. Например, как представлено на фиг. 11, многоуровневый визуал 1100 дает возможность разработчику приложения избирательно управлять информацией в визуале через потоки множественных данных, обеспечивая более мелкую степень детализации управления относительно визуалов, имеющих единственный поток данных. Отметим, что подобная степень детализации управления может быть осуществлена наличием (например, трех) отдельных дочерних визуалов под единственным родительским визуалом, однако это требует, чтобы код программы работал с множественными визуалами, что более сложно, чем работа с единственным уровневым визуалом, имеющим индексы на множественные уровни. Посредством примера на фиг. 11 данные фона, данные содержимого и данные границы содержатся в единственном уровневом визуале, но отделены друг от друга, как индексировано величиной уровня, например 0, 1 или 2 соответственно. Уровни могут быть вставлены, включая присоединенные, на любой конец, и/или удалены, с порядком уровней (например, слева направо, как показано) определяющим подразумеваемый порядок Z для дисплея. Отметим, что для безопасности содержимое потомков и другие данные в уровневом визуале не может быть перенумерованным.

Другие типы визуалов включают в себя визуалы контейнера и повторно направленные дочерние визуалы HWnd, в которых содержимое нарисовано в растре и заключено в поверхностном визуале. Трехмерные визуалы делают возможным соединение между двумерными и трехмерными мирами, например, подобный камере вид возможен через двумерный визуал, имеющий вид в трехмерный мир.

Многие из объектов ресурсов являются неизменными после создания, а именно после того, как они созданы, они не могут быть изменены по различным причинам, включая вопросы упрощения прохождения, предотвращение искажения другими и упрощение взаимодействия с элементами и интерфейсами API. Отметим, что это в сущности упрощает систему. Следует отметить, однако, что можно иметь систему, где такие объекты являются изменчивыми, но, например, требовали бы управления графом зависимости. Например, хотя можно иметь систему, где такие объекты являются изменчивыми, если бы код программы изменил кадр, установленный на Визуал, визуал нуждался бы в повторной визуализации, таким образом, требуя механизма извещения/регистрации, например, если новый кадр назначен визуалу, визуал регистрирует себя с кадром для извещений (например, измененное кадром извещение). Таким образом, в одной реализации для целей упрощения объекты ресурсов являются неизменными.

Эти объекты ресурсов могут быть определены конструктором, что является прямым обобщенным путем для создания объекта или путем использования сопутствующего объекта построения, как описано ниже. Например, для создания SolidColorBrush (кисти чистого цвета), (объекты кисти описаны ниже), может использоваться конструктор:

Brush MyBrush = new SolidColorBrush (Colors.Red);

Пользователь может также использовать статические члены на классе Кистей для получения набора заданных цветов.

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

Таким образом, вместо использования конструктора для создания 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. Кроме того, имеется множество ресурсов и классов, которые совместно используются всем этим набором. Это включает в себя Pens (перья), Brushes (кисти), Geometry (геометрия), Transforms (преобразования) и Effects (эффекты). IDrawingContext выставляет множество операций рисования, которые могут использоваться для заполнения DrawingVisual, ValidationVisual. ISurfaceDrawingContext, базовый интерфейс для контекста IDrawing, может использоваться для заполнения SurfaceVisual. Другими словами, контекст рисования предоставляет множество операций рисования; для каждой операции рисования имеется два способа, один, который принимает константы как аргументы, и один, который принимает аниматоры как аргументы.

Метод DrawLine (нарисовать линию) рисует линию определенным пером от начальной точки до конечной точки.

Метод DrawRoundedRectangle рисует закругленный прямоугольник с определенными кистью и пером; кисть и перо могут быть фиктивными.

Метод DrawGeometry рисует путь определенными кистью и пером; кисть и перо могут быть фиктивными.

Метод DrawRectangle рисует прямоугольник определенными кистью и пером; кисть и перо могут быть фиктивными.

Метод DrawSurface рисует поверхность.

Geometry является типом класса (фиг. 12), который определяет заготовку векторной графики, без штриха или заполнения. Каждый объект геометрии имеет простую форму (LineGeometry, EllipseGeometry, RectangleGeometry), сложную единственную форму (PathGeometry) или список таких форм GeometryList с определенной операцией комбинирования (например, объединение, пересечение и т.д.). Эти объекты образуют иерархию классов, как представлено на фиг. 12.

Как представлено на фиг. 13, PathGeometry является коллекцией (объединением) объектов Фигуры. В свою очередь, каждый из объектов Фигуры состоит из одного или нескольких объектов Сегмента, которые действительно определяют форму фигуры. Фигура является подразделом Geometry, который определяет коллекцию сегментов. Эта коллекция сегментов является единственным соединенным рядом двумерных объектов Сегмента. Фигура может быть либо замкнутой формы с определенной областью, либо в точности соединенной последовательностью Сегментов, которые определяют кривую, но без замкнутой области.

Заполненная область PathGeometry определяется путем взятия содержащихся Фигур, которые имеют свое свойство Filled (заполнено), установленное равным значению "истина", и применения FillMode (режима заполнения) для определения замкнутой области. Отметим, что перечисление FillMode определяет, как пересекающиеся области объектов Фигуры, содержащиеся в Geometry, комбинируются для образования результирующей области Geometry. Правило «Альтернативный» определяет, находится ли точка внутри фильтра «холст», посредством концептуального рисования луча от этой точки в бесконечность в любом направлении, и затем исследования мест, где сегмент формы пересекает луч. Начиная c отсчета нуль и добавляя единицу каждый раз, когда Сегмент пересекает луч слева направо, и отнимая единицу каждый раз, когда сегмент пути пересекает луч справа налево, после подсчета пересечений, если результат равен нулю, то точка находится снаружи пути. В противном случае, она находится внутри. Правило «обмотки» определяет, находится ли точка на фильтре «холст» внутри, и работает посредством концептуального рисования луча от этой точки в бесконечность в любом направлении и подсчета количества Сегментов пути от заданной формы, которую пересекает луч. Если это число нечетное, то точка находится внутри; если четное, то точка находится снаружи.

Как представлено на фиг. 14, при рисовании геометрии (например, прямоугольника), может быть определена кисть или перо, как описано ниже. Кроме того, объект "перо" также имеет объект кисти. Объект "кисть" определяет, как графически заполнить плоскость, и имеется иерархия классов объектов кисти. Это представлено на фиг. 14 заполненным прямоугольником 1402, который образуется, когда обрабатывается визуал, включающий в себя прямоугольник и команды и параметры кисти.

Как описано ниже, некоторые типы Brushes (Кистей) (такие как градиенты и девять сеток) сами определяют свои размеры. При использовании размер для этих кистей получается из ограничивающего прямоугольника, например, когда GradientUnits/DestinationUnits для Brush установлен равным ObjectBoundingBox, используется ограничивающий прямоугольник примитива, который рисуется. Если эти свойства установлены равными UserSpaceOnUse, то используется координатное пространство.

Объект Pen (перо) поддерживается на Кисти вместе со свойствами для Width (ширина), LineJoin (соединить линией), LineCap (головка линии), MiterLimit (предел скоса), DashArray (штриховой массив) и DashOffset (штриховое смещение), как представлено в примере ниже:

Как указано выше, модель объекта графики данного изобретения включает в себя модель объекта Brush, которая обычно направлена на концепцию покрытия плоскости пикселами. Примеры типов кистей представлены в иерархии фиг. 15, и, под базовым классом Brush включают в себя SolidColorBrush, GradientBrush, ImageBrush, VisualBrush (который может ссылаться на Visual) и NineGridBrush (кисть девяти сеток). GradientBrush включает в себя объекты LinearGradient (линейный градиент) и RadialGradient (радиальный градиент). Как описано выше, объекты Brush являются неизменными.

Следующее излагает примерный класс BrushBuilder (построитель кисти):

Отметим, что объекты Brush могут распознавать, как они связаны с системой координат при их использовании и/или как они связаны с ограничивающим прямоугольником формы, на которой они используются. Обычно, такая информация, как размер, может быть получена от объекта, на котором рисуется кисть. Более конкретно, многие типы кистей используют систему координат для определения некоторых из их параметров. Эта система координат либо может быть определена как относительная к простому ограничивающему прямоугольнику формы, к которой применяется кисть, или она может быть относительной к координатному пространству, которое активно во время, когда используется кисть. Это известно, соответственно, как режим ObjectBoundingBox (ограничивающий объект прямоугольник) и режим UserSpaceOnUse (используется пространство пользователя).

Объект SolidColorBrush заполняет идентифицируемую плоскость чистым цветом. Если имеется компонент alpha цвета, то он комбинируется мультипликативным способом с соответствующим атрибутом непрозрачности в базовом классе Brush. Следующее излагает примерный объект SolidColorBrush (кисть чистого цвета):

Объекты GradientBrush, или просто градиенты, обеспечивают градиентное заполнение и рисуются посредством определения множества градиентных остановок, которые определяют цвета вместе с некоторым типом продвижения. Градиент рисуется посредством выполнения линейных интерполяций между градиентными остановками в цветовом пространстве gamma 2,2 RGB; интерполяция через другие значения gamma или другие цветовые пространства (HSB, CMYK и т.д.), также является возможной альтернативой. Два типа объектов градиента включают в себя линейный и радиальный градиенты.

Обычно градиенты составлены из списка градиентных остановок. Каждая из этих градиентных остановок содержит цвет (с включенным значением alpha) и смещение. Если нет определенных градиентных остановок, то кисть рисуется как сплошной прозрачный черный цвет, как будто вообще не было определенной кисти. Если имеется только одна определенная градиентная остановка, то кисть рисуется как сплошной цвет с определенным одним цветом. Подобно другим классам ресурсов, класс градиентных остановок (пример в таблице внизу) является неизменным.

Имеется также класс коллекции, как изложено в следующем примере:

Как представлено в таблице внизу, GradientSpreadMethod определяет, как следует рисовать градиент снаружи определенного вектора или пространства. Имеется три величины, включая участок, в котором крайние цвета (первый и последний) используются для заполнения остающегося пространства, отражение, в котором остановки воспроизводятся в обратном порядке повторно для заполнения пространства, и повторение, в котором остановки повторяются в порядке, пока не заполнится пространство:

Фиг. 16 показывает примеры GradientSpreadMethod (метода распространения градиента). Каждая форма имеет линейный градиент, идущий от белого к серому цвету. Сплошная линия представляет вектор градиента.

LinearGradient определяет кисть с линейным градиентом вдоль вектора. Индивидуальные остановки определяют остановки цветов вдоль этого вектора. Пример показан в таблице внизу:

RadialGradient в модели программирования подобен линейному градиенту. Однако, хотя линейный градиент имеет точку начала и конца для определения вектора градиента, радиальный градиент имеет окружность вместе с точкой фокуса для определения поведения градиента. Окружность определяет концевую точку градиента, а именно остановка градиента при 1,0 определяет цвет на окружности. Точка фокуса определяет центр градиента. Остановка градиента при 0,0 определяет цвет в точке фокуса.

Фиг. 17 показывает радиальный градиент от белого к серому цвету. Наружная окружность представляет окружность градиента, тогда как точка обозначает точку фокуса. Этот примерный градиент имеет свой SpreadMethod, установленный на Pad (участок):

Другим объектом кисти, представленным на фиг. 15, является объект VisualBrush. Концептуально, Visualbrush обеспечивает способ иметь визуал, нарисованный повторяемым мозаичным способом в качестве заполнения. Это представлено на фиг. 14 визуальной кистью, ссылающейся на визуал (и какие-либо дочерние визуалы), который определяет единственную круговую форму 1420, с этой круговой формой, заполняющей прямоугольник 1422. Таким образом, объект VisualBrush может ссылаться на визуал, для определения того, как эта кисть должна быть нарисована, что вводит тип множественного использования для визуалов. Таким образом, программа может использовать произвольный графический «метафайл» для заполнения области кистью или пером. Так как это сжатая форма для сохранения и использования произвольной графики, она служит ресурсом графики. Следующее излагает примерный объект VisualBrush:

Содержимое VisualBrush не имеет собственных границ и эффективно описывает бесконечную плоскость. Это содержимое существует в своем собственном координатном пространстве, и это пространство, которое заполняется VisualBrush, является локальным координатным пространством во время приложения. Пространство содержимого отображается в локальное пространство, основанное на свойствах ViewBox (прямоугольник вида), ViewPort (отверстие вида), Alignments (выравнивания) и Stretch (растягивание). ViewBox определен в пространстве содержимого, и этот прямоугольник отображается в прямоугольник ViewPort (как определено через свойства Origin - происхождение и Size - размер).

ViewPort определяет местонахождение, где содержимое в конечном счете будет нарисовано, с созданием мозаичного размещения для этой Кисти. Если значением DestinationUnits (ячейки назначения) является UserSpaceOnUse (пространство пользователя для использования), то считается, что свойства Origin (происхождение) и Size (размер) находятся в локальном пространстве во время приложения. Если вместо этого значением DestinationUnits является ObjectBoundingBox (ограничивающий объект прямоугольник), то считается, что Origin и Size находятся в координатном пространстве, где 0,0 - верхний/левый угол ограничивающего прямоугольника закрашиваемого объекта, а 1,1 - нижний/правый угол этого же прямоугольника. Например, рассмотрим заполняемую RectangleGeometry (геометрию прямоугольника), которая рисуется от 100,100 до 200,200. В этом примере, если DestinationUnits является UserSpaceOnUse, Origin 100,100 и Size 100,100 описывали бы всю область содержимого. Если DestinationUnits является ObjectBoundingBox, Origin 0,0 и Size 1,1 описывали бы всю область содержимого. Если Size пусто, то эта Кисть ничего не визуализирует.

ViewBox задается в пространстве содержимого. Этот прямоугольник преобразуется для совпадения в пределах ViewPort, как определено свойствами Alignment и свойством Stretch. Если Stretch пусто, то к содержимому не применяется масштабирование. Если Stretch является Fill (заполнение), то ViewBox масштабируется независимо как в оси Х, так и в оси Y, для того чтобы быть того же размера, что и ViewPort. Если Stretch является Uniform (однородным) или UniformToFill (однородным для заполнения), логика такая же, но размерности X и Y масштабируются однородно, сохраняя коэффициент сжатия содержимого. Если Stretch является Uniform, ViewBox масштабируется для того, чтобы иметь более ограниченную размерность, равную размеру ViewPort. Если Stretch является UniformToFill, то ViewBox масштабируется для того, чтобы иметь менее ограниченную размерность, равную размеру ViewPort. Другими словами, как Uniform, так и UniformToFill сохраняют коэффициент сжатия изображения, но Uniform обеспечивает то, что весь ViewBox находится в пределах ViewPort (потенциально оставляя части ViewPort, непокрытыми ViewBox), и UniformToFill обеспечивает то, что весь ViewPort заполнен ViewBox (потенциально оставляя части ViewBox снаружи ViewPort). Если ViewBox пуст, то не применяется Stretch. Отметим, что выравнивание все же происходит, и оно расположит «точку» ViewBox.

Фиг. 18 обеспечивает представление единственной мозаики 1800 графики, визуализируемой с различными установками растяжения, включая мозаику 800, где растяжение установлено равным значению «пусто». Мозаика 1802 является представлением того, когда растяжение установлено равным «Uniform», мозаики 1804, когда растяжение установлено равным «UniformToFill», и мозаики 1806, когда растяжение установлено равным «Fill».

После определения ViewPort (на основе DestinationUnits - целевые ячейки) и после определения размера ViewBox, ViewBox нуждается в расположении в пределах ViewPort. Если ViewBox имеет такой же размер, что и ViewPort (если Stretch является Fill, или если это имеет место с одним из трех других величин Stretch), то ViewBox располагается в Origin так, чтобы быть идентичным для ViewPort. В противном случае рассматриваются HorizontalAlignment (горизонтальное выравнивание) и VerticalAlignment (вертикальное выравнивание). На основе этих свойств ViewBox выравнивается в измерениях как по X, так и по Y. Если HorizontalAlignment является Left (левым), то левый край ViewBox будет расположен на левом краю ViewPort. Если это Center (центр), то центр ViewBox будет расположен в центре ViewPort, а если Right (правый), то будут удовлетворены требования правых краев. Процесс повторяется для измерения по Y.

Если ViewBox является (0,0,0,0), он рассматривается не установленным, посредством чего рассматривается ContentUnits (ячейки содержимого). Если ContentUnits является UserSpaceOnUse, не происходит масштабирования или смещения, и содержимое рисуется в ViewPort без преобразования. Если ContentUnits является ObjectBoundingBox, то происхождение содержимого выравнивается с ViewPort Origin, и содержимое масштабируется шириной и высотой ограничивающего объект прямоугольника.

При заполнении пространства с помощью VisualBrush, содержимое отображается в ViewPort, как и выше, и отсекается во ViewPort. Это образует базовую мозаику для заполнения, и оставшаяся часть пространства заполняется на основе Brush's TileMode (режим мозаики кисти). Наконец, если установлено, преобразование кисти применяется - оно происходит после всего другого отображения, масштабирования, смещения и т.д. Перечисление TileMode используется для описания того, заполняется ли пространство своей Кистью и как оно заполняется. Кисть, которая может быть размещена мозаично, имеет определенный прямоугольник мозаики, и эта мозаика имеет базовое местонахождение в пределах заполняемого пространства. Остальная часть пространства заполняется на основе значения TileMode. Фиг. 19 обеспечивает представление примерной графики с различными установками TileMode, включая «Пусто» 1900, «Мозаика» 1092, «Обращение Х» 1904, «Обращение Y» 1906 и «Обращение XY» 1908. Верхняя самая левая мозаика в различных примерных графиках содержит базовую мозаику.

Фиг. 20 представляет процесс для генерации пикселов для этой кисти. Отметим, что логика, описанная на фиг. 20, является только одним возможным способом реализации логики, и следует понимать, что возможны и другие способы, включая более эффективные способы. Например, вероятно имеются более эффективные способы обработки данных, например, такие, при которых содержимое не рисуется для каждого повторения, с нарисованной и кэшированной мозаикой. Однако фиг. 20 обеспечивает прямое описание.

В сущности, каждый раз, когда рисуется содержимое образца, создается новая система координат. Происхождение и смещение каждого повторения описывается свойствами Origin и Size, профильтрованными через свойства DestinationUnits и Transform.

Координатный кадр устанавливается на основе свойства DestinationUnits. С этой целью, если на стадии 2000, свойством DestinationUnits является UserSpaceOnUse, текущим координатным кадром во время использования кисти является начальный координатный кадр, через этап 2002. Если вместо этого на этапе 2004 свойство является ObjectBoundingBox, ограничивающий прямоугольник геометрии, к которому применяется эта кисть, используется, как представлено этапом 2004, для установления нового координатного кадра, такого, что верхний левый угол ограничивающего прямоугольника отображается в (0,0), и нижний левый угол ограничивающего прямоугольника отображается в (1,1). В любом случае, на этапе 2006 свойство Transform применяется к этому координатному кадру, который по существу определяет сетку.

Фиг. 21 представляет VisulBrush Grid (сетку), которая определена для мозаик в VisualBrush. Первый круг является простой сеткой, а второй имеет Transform с Skew (перекосом) в направлении х 47.

На этапе 2008 визуал рисуется в каждую ячейку сетки, как представлено на фиг. 22, где визуал рисует соответствующие данные. Если на этапе 2010 имеется определенный ViewBox, Визуал вписывается в ячейку сетки, как определено атрибутами ViewBox, Stretch, HorizontalAlign и VerticalAlign, на этапе 2012. Свойства DestinationUnits и Transform используются для применения правильного преобразования, такого, что визуал выравнивается с прямоугольником сетки.

Если нет определенного ViewBox, то новая система координат устанавливается для рисования содержимого на этапе 2014.

Координатный кадр устанавливается таким образом, что его происхождение находится в точке Origin для этой рисуемой конкретной ячейки сетки. Усечение применяется на этапе 2018 на основе свойства Size таким образом, что эта мозаика не будет рисоваться вне границ ячейки. Origin и Size модифицируются соответствующим образом на основе свойства DestinationUnits.

Система координат затем модифицируется на основе свойства SourceUnits (исходные ячейки). С этой целью, если на этапе 2020 свойством SourceUnits является ObjectBoundingBox, на этапе 2026 применяется соответствующее преобразование масштабирования, в противном случае это UserSpaceOnUse, и новое преобразование не применяется. Свойство Transform применяется на этапе 2024, и содержимое рисуется на этапе 2026.

Отметим, что если любая часть размера является нулем, ничего не рисуется, и если Stretch является «Пустым», преобразование для viewbox устанавливается таким образом, что одна ячейка в новом координатном кадре равна одной ячейке в старом координатном кадре. Преобразование по существу становится смещением на основе атрибутов выравнивания и размера ViewBox. Как описано выше на этапах 2010 и 2012, свойства Stretch и выравнивания применяются, только если имеется заданный ViewBox. ViewBox определяет новую систему координат для содержимого, и Stretch помогает определить, как это содержимое отображается в ViewBox. Опции выравнивания выравнивают ViewBox, а не содержимое. Таким образом, например, если viewbox установлен на «0 0 10 10» и что-нибудь рисуется при -10,-10 и выравнивается к верхнему левому углу, эта часть будет отсечена.

Если вернуться к фиг. 15, кисть изображения может представляться как специальный случай VisualBrush. Хотя программа может создать визуал, поместить в него изображение и присоединить его к VisualBrush, API для этого был бы громоздким. Так как нет необходимого координатного кадра содержимого, элементы свойств ViewBox и ContentUnits больше не применяются.

NineGridBrush (кисть девяти сеток) очень похожа на ImageBrush (кисть изображения), за исключением того, что изображение деформируется на основе размера. В сущности, NineGridBrush может представляться как специальный тип Stretch, в котором определенные части изображения растягиваются, тогда как другие (например, границы) не растягиваются. Таким образом, хотя Size изображения в ImageBrush вызовет простое масштабирование, NineGridBrush создаст неоднородный масштаб вплоть до желаемого размера. Ячейки для немасштабируемых областей являются ячейками пользователя, когда применяется кисть, что означает, что ContentUnits (ячейки содержимого) (если они существуют для NineGridBrush) будут установлены равными UserUnitsOnUse (используемые ячейки пользователя). Свойство Transform Кисти может быть эффективно использовано. Отметим, что элементы границы подсчитываются внутрь от края изображения.

Посредством примера фиг. 23 представляет изображение девяти сеток, увеличивающееся от первого случая 2302 ко второму случаю 2304, с четырьмя типами областей. Как представлено на фиг. 23, для удержания границы одинаковой области, помеченные «а», расширяются в горизонтальном направлении, области, помеченные «b», расширяются в вертикальном направлении, области, помеченные «с», расширяются в горизонтальном и вертикальном направлениях, и области, помеченные «d», не изменяют своего размера.

Как в общем описано выше, модель объекта графики согласно данному изобретению включает в себя модель объекта Transform, которая включает в себя типы преобразований, представленных в иерархии фиг. 24, под базовым классом Transform. Эти различные типы компонентов, которые образуют преобразование, могут включать в себя TransformList (список преобразований), TranslateTransform (преобразование сдвига), RotateTransform (преобразование вращения), ScaleTransform (преобразование масштаба), SkewTransform (преобразование скоса) и MatrixTransform (преобразование матрицы). Индивидуальные свойства могут быть «оживлены», например, разработчик программы может создать мультипликацию свойства Angle (угол) из RotateTransform.

Матрицы для двумерных вычислений представлены как матрица 3х3. Для необходимых преобразований, только шесть величин необходимы вместо полной матрицы 3х3. Они названы и определены следующим образом.

При умножении матрицы на точку, она преобразует эту точку от новой системы координат в предыдущую систему координат:

Преобразования могут быть вложенными до любого уровня. Когда бы новое преобразование не применялось, оно является таким же, что и последующее умножение его на текущую матрицу преобразования:

Большинство мест в API не принимают Matrix (матрицу) непосредственно, но вместо этого используют класс Transform, который поддерживает мультипликацию.

ЗАКЛЮЧЕНИЕ

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

Хотя изобретение является восприимчивым к различным модификациям и альтернативным конструкциям, некоторые иллюстрированные варианты его осуществления показаны в чертежах и были описаны выше подробно. Следует понимать, однако, что нет намерения ограничить изобретение раскрытыми специфическими формами, а напротив, имеется намерение охватить все модификации, альтернативные конструкции и эквиваленты, попадающие в пределы сущности и объема изобретения.