Интерфейсы визуального объекта и графа сцены

Изобретение относится к компьютерным системам, в частности к обработке графической и другой видеоинформации для отображения на компьютерных системах. Техническим результатом изобретения является улучшение технологии обработки графики. Этот результат достигается тем, что способ, реализуемый в вычислительной среде, в которой принимается программный код для одного или более объектов, и предназначенный для обеспечения сопряжения со структурой данных графа сцены для создания графики, содержит этапы, на которых принимают вызов функции, соответствующий программному коду на высокоуровневом языке разметки графики, на уровне визуального интерфейса прикладного программирования в формате, который обеспечивает возможность непосредственного размещения этого функционального вызова на упомянутый уровень интерфейса прикладного программирования; отвечают на вызов функции посредством модифицирования данных в графе сцены, активируют средство управления визуальными объектами для обхода графа сцены и визуализации по меньшей мере одного объекта на целевой объект визуализации и воспроизводят граф сцены на дисплее. 33 з.п. ф-лы, 21 ил.

 

Область техники, к которой относится изобретение

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

Предшествующий уровень техники

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

Новая модель управления выводом графики описывается в заявках на патент США №№ 10/184 795, 10/184 796, 10/185 775, 10/401 717, 10/402 322 и 10/402 268, правообладателем которых является правообладатель настоящего изобретения и которые настоящим включены в качестве ссылки. Данная новая модель обеспечивает ряд существенных улучшений в технологии обработки графики. Например, заявка на патент США № 10/184 795, в основном, относится к системе и способу многоуровневой обработки графики, в которых компонент более высокого уровня (например, операционной системы) выполняет интенсивные в отношении вычисления аспекты построения графа сцены, обновления параметров анимации и обхода структур данных графа сцены при относительно низкой рабочей скорости, чтобы передать упрощенные структуры данных и/или графические команды на компонент нижнего уровня. Так как обработка высокого уровня существенно упрощает данные, компонент нижнего уровня может работать при большей скорости (относительно компонента высокого уровня), например со скоростью, которая соответствует частоте регенерации кадров графической подсистемы, для обработки данных в постоянные данные вывода для графической подсистемы. Когда используется анимация, вместо необходимости перерисовки всей сцены с изменениями обработка нижнего уровня может интерполировать интервалы параметров как необходимо для получения мгновенных значений, которые при визуализации обеспечивают незначительно измененную сцену для каждого кадра, обеспечивая плавную анимацию.

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

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

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

Краткое изложение сущности изобретения

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

Большинство объектов ресурса в графе сцены являются неизменными после их создания, т. е., если они создаются, то они не могут быть изменены. Для тех объектов, которые разработчик хочет легко изменять, изменчивость обеспечивается изменяемым узором и реализацией, как описано в совместно рассматриваемой заявке на патент США, названной «Changeable Class and Pattern to Provide Selective Mutability in Computer Programming Environments» (Изменяемый класс и модель для получения селективной изменчивости в среде программирования для компьютеров), поданной одновременно с данной заявкой, правообладателем которой является правообладатель настоящего изобретения и которая включена в данную заявку посредством ссылки.

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

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

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

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

Удерживаемый визуальный объект работает аналогично визуальному объекту рисования за исключением того, что его содержимое рисования заполняется, когда система запрашивает, чтобы он был заполнен, вместо заполнения его при помощи программного кода. Например, если содержимое конкретного визуального объекта потребуется при визуализации сцены, система вызывает IRetainedVisual.Render для закрашивания содержимого Visual, заменяя любое содержимое, которое уже находится в памяти.

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

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

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

Перечень фигур чертежей

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

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

фиг.3 - представление графа сцены визуальных объектов и сопоставленные компоненты для обработки графа сцены, например, посредством обхода графа сцены для получения графических команд и других данных согласно аспекту настоящего изобретения;

фиг.4 - представление графа сцены визуальных объектов проверки достоверности, визуальных объектов рисования и ассоциированных списков инструкций, созданных согласно аспекту настоящего изобретения;

фиг.5 - представление класса визуального объекта объектной модели согласно аспекту настоящего изобретения;

фиг.6 - представление различных других объектов объектной модели согласно аспекту настоящего изобретения;

фиг.7 - представление иерархии классов преобразования согласно аспекту настоящего изобретения;

фиг.8 и 9 - представление преобразований данных визуального объекта при масштабировании геометрической формы и неравномерном масштабировании, соответственно, согласно аспекту настоящего изобретения;

фиг.10 - представление классов геометрических форм объектной модели согласно аспекту настоящего изобретения;

фиг.11 - представление структуры PathGeometry согласно аспекту настоящего изобретения;

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

фиг.13 - представление классов кистей объектной модели согласно аспекту настоящего изобретения;

фиг.14 и 15 - представление визуализированной графики, происходящей из данных в объекте кисти линейного градиента, согласно аспекту настоящего изобретения;

фиг.16 - представление визуализированной графики, происходящей из данных в объекте кисти радиального градиента, согласно аспекту настоящего изобретения;

фиг.17 - представление визуализированного объекта кисти с девятью ячейками сетки согласно аспекту настоящего изобретения;

фиг.18 - представление визуализированной графики, происходящей из различных значений растягивания, согласно аспекту настоящего изобретения;

фиг.19 - представление визуализированной графики, происходящей из различных значений элемента мозаики, согласно аспекту настоящего изобретения;

фиг.20 - представление сетки и преобразованной сетки, происходящей из данных в объекте кисти визуального объекта, согласно аспекту настоящего изобретения;

фиг.21 - представление сетки и преобразованной сетки с визуализированной графикой в ней, нарисованной из визуального объекта, согласно аспекту настоящего изобретения.

Подробное описание

Примерная рабочая среда

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

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

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

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

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

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

Компьютер 110 также может включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые носители данных компьютера. Только в качестве примера, на фиг.1 изображен накопитель 141 на жестких дисках, который считывает или записывает на несъемные энергонезависимые магнитные носители, магнитный дисковод 151, который считывает или записывает на съемный энергонезависимый магнитный диск 152, и оптический дисковод 155, который считывает или записывает на съемный энергонезависимый оптический диск 156, такой как компакт-диск или другой оптический носитель. Другие съемные/несъемные, энергозависимые/энергонезависимые носители данных компьютера, которые могут использоваться в примерной рабочей среде, включают в себя, но не в ограничительном смысле, кассеты с магнитной лентой, карты флэш-памяти, цифровые многофункциональные диски, цифровую видеоленту, твердотельное ОЗУ, твердотельное ПЗУ и т.п. Накопитель 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 при помощи интерфейса, такого как интерфейс 192 сенсорного экрана. Следует отметить, что монитор и/или панель с сенсорным экраном физически могут быть объединены с корпусом, в котором находится вычислительное устройство 110, как, например, в персональном компьютере планшетного типа, в котором панель 193 с сенсорным экраном служит, по существу, в качестве планшета 164. Кроме того, компьютеры, такие как вычислительное устройство 110, также могут включать в себя другие периферийные устройства вывода, такие как громкоговорители 195 и принтер 196, которые могут подключаться при помощи периферийного интерфейса 194 вывода или т. п.

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

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

Интерфейсы для структур данных графа сцены

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

Фиг.2 представляет общую многоуровневую архитектуру 200, в которой может быть реализовано настоящее изобретение. Как представлено на фиг.2, программный код 202 (например, прикладная программа, или компонент операционной системы, или т. п.) может быть разработан для вывода графических данных одним или несколькими различными образами, включая посредством формирования 204 изображения, при помощи элементов 206 векторной графики и/или при помощи вызовов функции/метода, размещаемых непосредственно на уровне 212 визуального интерфейса прикладного программирования (ИПП), согласно аспекту настоящего изобретения. Вообще говоря, формирование 204 изображения предусматривает программный код 202 с механизмом для загрузки, редактирования и сохранения изображений, например растров. Как описано ниже, эти изображения могут использоваться другими частями системы, и также существует возможность использовать код рисования примитивов для непосредственного рисования изображения. Элементы 206 векторной графики обеспечивают другой путь рисования графики, согласующийся с остальной объектной моделью (описанной ниже). Элементы 206 векторной графики могут быть созданы при помощи языка разметки, который система 208 элементов/свойств и система 210 разбивки интерпретируют для выполнения соответствующих вызовов на уровне 212 визуального ИПП. Элементы 206 векторной графики, вместе с системой 208 элементов/свойств и системой 210 разбивки, описываются в заявке на патент США № 10/401 717.

В одной реализации многоуровневая архитектура 200 графики включает в себя ядро 214 компоновки и анимации высокого уровня, которое включает в себя или иным образом ассоциировано со структурой 216 данных кэширования. Структура 216 данных кэширования содержит граф сцены, содержащий иерархически расположенные объекты, управление которыми осуществляется согласно определенной объектной модели, как описано ниже. Вообще говоря, уровень 212 визуального ИПП обеспечивает программный код 202 (и систему 210 разбивки) интерфейсом к структуре 216 данных кэширования, включая возможность создания объектов, открытия и закрытия объектов для предоставления им данных, и т. д. Другими словами, средство 214 компоновки и анимации высокого уровня предоставляет уровень 212 ИПП объединенной среды, посредством которого разработчики могут выразить намерения в отношении графики и среды для отображения графической информации и предоставления нижележащей платформе достаточной информации, так чтобы эта платформа могла оптимизировать использование аппаратных средств для программного кода. Например, нижележащая платформа будет ответственна за кэширование, согласование ресурсов и интеграцию сред.

В одной реализации средство 214 компоновки и анимации высокого уровня пропускает поток инструкций и, возможно, другие данные (например, указатели на растры) на быстродействующее средство 218 компоновки и анимации нижнего уровня. Как используется в данной заявке, термины «высокого уровня» и «нижнего уровня» аналогичны терминам, используемым в других вычислительных алгоритмах, в которых, вообще говоря, чем ниже программный компонент находится относительно компонентов более высокого уровня, тем ближе этот компонент к аппаратным средствам. Таким образом, например, графическая информация, посылаемая от средства 214 компоновки и анимации высокого уровня, может приниматься ядром 218 компоновки и анимации нижнего уровня, где эта информация используется для посылки графических данных на графическую подсистему, включающую в себя аппаратные средства 222.

Средство 214 компоновки и анимации высокого уровня совместно с программным кодом 202 строит граф сцены, чтобы представлять графическую сцену, обеспечиваемую программным кодом 202. Например, каждый элемент, подлежащий рисованию, может загружаться при помощи инструкций рисования, которые система может кэшировать в структуре 216 данных графа сцены. Как описано ниже, существует несколько различных путей задания этой структуры 216 данных и того, что рисуется. Далее, средство 214 компоновки и анимации высокого уровня интегрируется с системами 220 синхронизации и анимации для обеспечения декларативного (или другого) управления анимацией (например, интервалами анимации) и управления синхронизацией. Следует отметить, что система анимации дает возможность направлять значения анимации, по существу, куда угодно в системе, включая, например, уровень 208 элементов/свойств, внутри уровня 212 визуального ИПП, и в любом из других ресурсов. Система синхронизации предоставлена на уровнях элементов и визуальных объектов.

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

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

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

На фиг.3 и 4 показаны примерные графы 300 и 400 сцены, соответственно, включающие в себя базовый объект, упоминаемый как Visual. Визуальные объекты, или просто Visual, представляют собой контейнеры для графического содержимого, такого как линии, текст и изображения. Как представлено в наследовании объектов классов визуальных объектов на фиг.5, существует несколько различных визуальных объектов, включая ContainerVisual, который представляет собой Visual, который не содержит непосредственно графическое содержимое, но содержит порожденные объекты DrawingVisual. Порожденные объекты DrawingVisual добавляются к ContainerVisual, а не к другим объектам DrawingVisual. Это дает возможность разработчику выполнять изменения и устанавливать свойства на индивидуальных визуальных объектах без повторного создания и затем повторной визуализации всего контекста рисования, в то же самое время также разрешая доступ к свойствам отсечения и преобразования на контейнерном объекте. Объекты ContainerVisual могут быть вложенными.

DrawingVisual представляет собой Visual, который может содержать графическое содержимое. Данный Visual предоставляет ряд методов рисования. Порожденные объекты DrawingVisual организованы в пространство с отсчетом от нуля и упорядоченностью по z-координате. RetainedVisual представляет собой Visual, который вводит «удерживаемый поток инструкций», который может использоваться для рисования. Простым языком, RetainedVisual дает возможность разработчику удерживать содержимое визуального объекта и перерисовывать его только тогда, когда это необходимо. Можно использовать RetainedVisual императивно, аналогично DrawingVisual, при помощи вызова RenderOpen и использования возвращаемого DrawingContext для рисования. RetainedVisual обеспечивает функциональную возможность обратного вызова проверки достоверности и метод InvalidateVisual. Чтобы использовать функциональную возможность проверки достоверности, пользователь выполняет интерфейс IRetainedRender на RetainedVisual или классе, который является производным от него.

Ссылаясь на фиг.5, еще одним визуальным объектом является HwndVisual 505, который представляет собой Visual, используемый для обеспечения унаследованного управления или окна Microsoft® Win32® в качестве порожденного визуального объекта внутри визуальной сцены графа сцены. Более конкретно, унаследованные программы будут по-прежнему работать при помощи метода WM_PAINT (или аналогичного), который рисует в порожденном HWnd (или аналогичном), основываясь на предшествующей графической технологии. Для поддержки таких программ в новой модели обработки графики HwndVisual дает возможность Hwnd входить в состав графа сцены и перемещаться при изменении позиции порождающего визуального объекта. Также допустимы другие типы визуальных объектов, такие как трехмерные (3D) визуальные объекты, которые дают возможность организовать связь между двухмерным и трехмерным миром, например вид, подобный полученному камерой, возможен при помощи двумерного визуального объекта, имеющего вид в трехмерный мир.

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

Типовая прикладная программа может рисовать графику посредством определения разбивки в «XAML», как описано в вышеупомянутой заявке на патент США № 10/401 717, и также посредством задания некоторых операций рисования на языке программирования C#. Разработчики могут создавать элементы Shape или рисовать геометрические формы, используя классы Geometry с примитивами. В нижеследующем сценарии код демонстрирует рисование эллипса в Visual, который лежит в основании Canvas:

Используя визуальный ИПП, разработчики вместо этого могут рисовать непосредственно в Visual (к которому иначе обращались бы при помощи элемента разбивки).

Для визуализации содержимого объекта DrawingVisual прикладная программа обычно вызывает метод RenderOpen из DrawingVisual. RenderOpen возвращает DrawingContext, с которым прикладная программа может выполнять операции рисования. Для очистки содержимого Visual прикладная программа вызывает Close из DrawingContext. После вызова прикладной программой Close, DrawingContext больше может не использоваться.

Следующий код рисует эллипс (такой же эллипс, что и в предыдущем примере) в DrawingVisual, используя объект Geometry, а не форму Ellipse. В примере создают DrawingVisual, получают DrawingContext из DrawingVisual и вызывают метод DrawGeometry из DrawingContext для рисования эллипса. Следует отметить, что необходимо добавить Visual к дереву визуальных объектов объекта верхнего уровня, который, в данном случае, представляет собой окно.

Следующий пример дополняет предыдущий пример посредством добавления аналогичных эллипсов к ContainerVisual (следует отметить, что этот пример подробный для ясности). Использование ContainerVisual может содействовать организации объектов сцены и дает возможность разработчику отделить объекты Visual, в отношении которых должна быть выполнена проверка принадлежности или проверка достоверности (объекты RetainedVisual), от обычного нарисованного содержимого и минимизировать необязательную перерисовку содержимого.

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

На базовом уровне пользователь может создавать и использовать RetainedVisual аналогично DrawingVisual; т. е. пользователь может вызвать RenderOpen и получить DrawingContext. Альтернативно, пользователь может выполнить интерфейс IRetainedRender на RetainedVisual. Выполнив это, пользователи гарантируют то, что графическая система будет использовать значение, установленное в свойстве RenderBounds, в качестве границ для содержимого, подлежащего визуализации при вызове IRetainedVisual.Render.

При визуализации сцены графическая система будет исследовать любой порожденный Visual. Если значение свойства RenderBounds указывает, что конкретное содержимое Visual будет необходимо при визуализации сцены, система вызывает IRetainedVisual.Render для закрашивания содержимого Visual, заменяя любое содержимое, уже находящееся в памяти. Прикладная программа также может вызвать InvalidateVisual непосредственно для очистки содержимого из Visual. Если прикладная программа не выполнила IRetainedRender на RetainedVisual, любой вызов InvalidateVisual будет создавать исключительную ситуацию.

Следующий код реализует класс, который выполняет IRetainedRender на RetainedVisual и рисует в нем.

Визуальный ИПП, подобно остальной части графической системы настоящего изобретения, представляет собой управляемый ИПП и использует типовые признаки управляемого кода, включая строгий контроль типов и чистку памяти («сбор мусора»). Он также использует возможности аппаратного ускорения для визуализации. Чтобы оказать услугу разработчикам, работающим с существующими неуправляемыми прикладными программами, визуальный ИПП обеспечивает ограниченную возможность взаимодействия между настоящей графической системой и службами визуализации, основанными на интерфейсе графических устройств (ИГУ, GDI) Microsoft Windows®.

Эта возможность взаимодействия позволяет разработчикам обеспечивать основанные на ИГУ окна в прикладных программах с доступом к Visual, используя объект Hwnd Visual, элементы управления записью и тематическое оформление, которые основаны на рисовании и визуализации настоящего изобретения, но по-прежнему работают в унаследованных прикладных программах ИГУ и прикладных программах, основанных на Modify GDI HWND, используя преимущество новых функциональных возможностей визуализации, включая аппаратное ускорение и цветовую модель.

HwndVisual дает возможность обеспечивать содержимое Win32 в прикладной программе с доступом к Visual. Как представлено на фиг.5, HwndVisual наследуется от ContainerVisual. Следует отметить, что нельзя смешивать ИГУ и новые модели рисования в одном HwndVisual. Вместо этого этот визуальный объект может быть более полезным для унаследованных элементов управления ограниченного объема. Следующий пример демонстрирует создание элемента управления в HwndVisual и добавление его к дереву визуальных объектов.

Как и с другими объектами, можно применять преобразования и другие изменения свойств к элементу управления, если он обеспечивается в Visual.

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

Для рисования VisualManager 304 обрабатывает (например, обходит или передает) граф сцены, как запланировано диспетчером 308, и предоставляет графические инструкции и другие данные на компонент 218 нижнего уровня (фиг.2) для его соответствующего окна 306, как, в основном, описано в вышеупомянутых заявках на патент США. Обработка графа сцены первоначально планируется диспетчером 308 в соответствии с частотой, которая относительно более низкая по сравнению с частотой регенерации компонента 218 нижнего уровня и/или графической подсистемы 222.

На фиг.3 изображен ряд порожденных Visual 310-314, расположенных иерархически под Visual 302 верхнего уровня (корневого), некоторые из которых представлены заполненными посредством контекстов 316, 317 рисования (показанных в виде пунктирных прямоугольников для представления их временной сущности) ассоциированными списками 318 и 319 инструкций, соответственно, например содержащие Instruction List и другие Visual. Visual также могут содержать другую информацию о свойствах. Вообще говоря, большая часть обращений к базовому классу визуального объекта происходит при помощи интерфейса IVisual, и визуальный объект является производным от DependencyObject, как представлено на фиг.5. Среди других графических примитивов список инструкций может включать в себя ссылку на ImageData. Данный ImageData затем может быть изменен/обновлен непосредственно получением из него контекста рисования, или получением SurfaceVisualRenderer (альтернативно названный ImageDataVisualRenderer).

Визуальные объекты предлагают службы посредством предоставления отсечения, непрозрачности и, возможно, других свойств, которые могут быть установлены и/или считаны при помощи метода get. Кроме того, визуальный объект имеет флаги, управляющие тем, как он участвует в проверке принадлежности. Свойство Show используется для того, чтобы показать/скрыть визуальный объект, например, когда равен false (ложь), визуальный объект невидим, иначе - визуальный объект является видимым. Кроме того, эти объекты (или Visual на уровне визуального ИПП, или элементы на уровне элементов) существуют в иерархии. Система координат наследуется вниз по этой иерархии. Таким образом, порождающий объект может поместить в стек преобразование координат, которое модифицирует проход визуализации и применяет к порожденному объекту этого порождающего объекта.

Преобразование для визуального объекта связано с этим визуальным объектом. Другими словами, оно устанавливается при помощи [Get|Set]ChildTransform на интерфейсе IVisual порождающего объекта.

Следует отметить, что преобразование координат может применяться равномерно ко всему, как если бы это было в растре. Следует отметить, что это не значит, что преобразования всегда применяются к растрам, но то, что визуализируется, подвергается преобразованию в равной степени. В качестве примера, если пользователь рисует круг при помощи круглого пера, ширина которого один дюйм, и затем применяет к этому кругу масштабирование по размеру Х в два раза, то ширина пера будет равна двум дюймам слева и справа и только одному дюйму вверху и внизу. Это иногда упоминается как компоновка или преобразование растра (в противоположность масштабированию каркаса или геометрической формы, которое затрагивает только геометрическую форму). На фиг.8 изображено представление преобразования масштабирования, причем непреобразованное изображение 800 расположено слева, и преобразованное изображение 802 с неравномерным масштабированием расположено справа. На фиг.9 изображено представление преобразования масштабирования, причем непреобразованное изображение 800 расположено слева, и преобразованное изображение 904 с масштабированием геометрической формы расположено справа.

В отношении преобразования координат визуального объекта, TransformToDescendant преобразует точку из эталонного визуального объекта в визуальный объект-потомок. Точка преобразуется из координатного пространства постпреобразования эталонного визуального объекта в координатное пространство постпреобразования визуального объекта-потомка. TransformFromDescendant преобразует точку из визуального объекта-потомка вверх по порождающей цепочке в эталонный визуальный объект. Точка преобразуется из координатного пространства постпреобразования визуального объекта-потомка в координатное пространство постпреобразования эталонного визуального объекта. Пользователь может получить Matrix в потомок и из него и из любого произвольного визуального объекта и в него. Доступны два свойства, которые могут использоваться для определения ограничивающего прямоугольника содержимого Visual, а именно DescendantBounds, который представляет собой ограничивающий прямоугольник потомков, и ContentBounds, который представляет собой границы содержимого. Применение Union к ним обеспечивает совокупные границы.

Свойство отсечения устанавливает (и получает) регион отсечения визуального объекта. Любой Geometry (класс геометрической формы показан на фиг.10) может использоваться в качестве региона отсечения, и регион отсечения применяется в координатном пространстве Post-Transformation. При одной реализации установкой по умолчанию для региона отсечения является null (нуль), т. е. нет отсечения, которое может рассматриваться как бесконечно большой прямоугольник отсечения от (-∞, -∞) до (+∞, +∞).

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

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

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

void PushTransform(Transform transform);

void PushTransform(Matrix matrix);

void Pop().

Аналогично, метод PushOpacity помещает в стек значение непрозрачности. Последующие операции рисования визуализируются на временной поверхности с заданным значением непрозрачности и затем компонуются в сцену. Pop() извлекает из стека непрозрачность, помещенную в стек соответствующим вызовом PushOpacity:

void PushOpacity(float opacity);

void PushOpacity(FloatAnimation opacity);

void Pop().

Метод PushClip помещает в стек геометрическую форму отсечения. Последующие операции рисования отсекаются до геометрической формы. Отсечение применяется в пространстве постпреобразования. Pop() извлекает из стека регион отсечения, помещенный в стек соответствующим вызовом PushClip:

void PushClip(Geometry clip);

void Pop().

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

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

На фиг.4 показан примерный граф 400 сцены, в котором ContainerVisual и DrawingVisual (и другие) связаны в графе сцены и имеют ассоциированные данные в виде Instruction List (списков инструкций) (например, в соответствующих контекстах рисования). ContainerVisual представляет собой контейнер для Visual, и ContainerVisual могут быть вложены друг в друга. Порожденными объектами ContainerVisual можно манипулировать при помощи методов на интерфейсе IVisual, который реализует ContainerVisual. Порядок объектов Visual в VisualCollection определяет то, в каком порядке визуализируются эти Visual, т. е. объекты Visual визуализируются от наименьшего индекса к наибольшему индексу от задней стороны к передней (порядок закрашивания).

Как описано выше, визуальные объекты могут рисоваться посредством заполнения их контекстов рисования различными графическими примитивами, включающими в себя Geometry, ImageSource и MediaData. Кроме того, существует группа ресурсов и классов, которые используются совместно при помощи этого целого стека. Они включают в себя Pen, Brush, Geometry, Transform и Effect. Абстрактный класс DrawingContext предоставляет набор операций рисования, которые могут использоваться для заполнения DrawingVisual, ValidationVisual, ImageData и т. д. Другими словами, абстрактный класс контекста рисования предоставляет набор операций рисования; для каждой операции рисования существует два метода: один метод, который принимает константы в качестве аргументов, и другой метод, который принимает аниматоры в качестве аргументов.

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

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

Как представлено на фиг.12, когда рисуется геометрическая форма (например, прямоугольник), может задаваться кисть или перо, как описано ниже. Кроме того, объект пера также имеет объект кисти. Объект кисти определяет то, как графически закрашивать плоскость, и существует иерархия класса объектов кисти. Это представлено на фиг.12 закрашенным прямоугольником 1202, который получается тогда, когда обрабатывается визуальный объект, включающий в себя инструкции и параметры прямоугольника и кисти. Объект Pen содержит Brush вместе со свойствами для Width, LineJoin, LineCap, MiterLimit, DashArray и DashOffset, как описано ниже. Как также описано ниже, некоторые типы Brush (такие как градиентные и с девятью ячейками сетки) сами устанавливают размер. Когда они используются, размер для этих кистей получают из ограничивающего прямоугольника, например, когда GradientUnits/DestinationUnits для Brush устанавливается на RelativeToBoundingBox, используется ограничивающий прямоугольник примитива, который рисуется. Если данные свойства устанавливаются на Absolute, то тогда используется координатное пространство.

Графическая объектная модель настоящего изобретения включает в себя объектную модель Brush, которая, в основном, направлена на принцип покрытия плоскости пикселями. Примеры типов кистей представлены в иерархии по фиг.13 и под базовым классом Brush включают в себя GradientBrush, NineGridBrush, SolidColorBrush и TileBrush. GradientBrush включает в себя объекты LinearGradient и RadialGradient. DrawingBrush и ImageBrush являются производными от TileBrush. Допустимы альтернативные классификации классов, например производными от TileBrush могут быть ImageBrush, VisualBrush, VideoBrush, NineGridBrush и Drawing Brush. Следует отметить, что объекты Brush могут распознавать, как они связаны с системой координат, когда они используются, и/или как они связаны с ограничивающим прямоугольником формы, на которой они используются. Вообще говоря, информация, такая как размер, может выводиться из объекта, на котором рисует кисть. Более конкретно, многие типы кистей используют систему координат для определения их некоторых параметров. Данная система координат может или определяться относительно простого ограничивающего прямоугольника формы, к которой применяется кисть, или она может быть относительной координатного пространства, которое является активным в тот момент, когда используется кисть. Они известны, соответственно, как режим RelativeToBoundingBox и режим Absolute.

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

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

Вообще говоря, градиенты состоят из списка ограничителей градиента. Каждый из этих ограничителей градиента содержит цвет (с включенным в него альфа-фактором) и смещение. Если не заданы ограничители градиента, кисть рисует чистым прозрачным черным цветом, как если бы кисть совсем не была задана. Если задан только один ограничитель градиента, кисть рисует чистым цветом с одним заданным цветом. Подобно другим классам ресурсов, класс ограничителей градиента (пример в таблице ниже) является производным от изменяемого класса (Changeable) и, таким образом, является селективно изменяемым, как описано в заявке на патент США, названной «Changeable Class and Pattern to Provide Selective Mutability in Computer Programming Environments» (Изменяемый класс и модель для обеспечения селективной изменчивости в средах программирования для компьютеров).

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

Градиенты состоят из списка ограничителей градиента. Каждый из этих ограничителей градиента содержит цвет (с включенным в него альфа-фактором) и смещение. Если не заданы ограничители градиента, кисть рисуется прозрачной (как если бы кисть не была задана). Если задан только один ограничитель градиента, кисть рисует чистым цветом с одним заданным цветом. Рассматриваются любые ограничители градиента со смещениями в диапазоне от нуля до единицы (0,0 … 1,0), причем наибольший ограничитель находится в диапазоне (-∞ … 0,0] и наименьший ограничитель находится в диапазоне [1,0 … +∞). Если набор рассматриваемых ограничителей включает в себя ограничитель, который находится вне диапазона от нуля до единицы, то неявный ограничитель получается в нуле (и/или единице), который представляет интерполируемый цвет, который имел бы место в этом ограничителе. Также, если два или более ограничителей устанавливаются с одинаковым смещением, строго определенный переход (а не интерполированный) имеет место при данном смещении. Порядок, в котором добавляются ограничители, определяет поведение при данном смещении; первый ограничитель, подлежащий добавлению, представляет собой реальный цвет перед этим смещением, последний ограничитель, подлежащий установке, представляет собой реальный цвет после данного ограничителя, и игнорируются любые дополнительные ограничители при данном смещении.

Данным классом является Changeable, аналогично другим классам ресурсов:

Аналогично SolidColorBrush он имеет вложенные Changeable в коллекциях анимации.

Перечисление GradientSpreadMethod задает то, как градиент должен рисоваться вне заданного вектора или пространства. Существует три возможных значения, включая Pad, в котором конечные цвета (первый и последний) используются для закрашивания остального пространства, Reflect, в котором ограничители циклически воспроизводятся в обратном порядке для закрашивания пространства, и Repeat, в котором ограничители повторяются по порядку до тех пор, пока пространство не будет закрашено. Значением по умолчанию для свойств этого типа является Pad:

На фиг.14 и 15 представлены некоторые примеры GradientSpreadMethod (хотя и в градации серого, а не в цвете). Каждая форма имеет линейный градиент, проходящий от белого до серого. Сплошная линия представляет вектор-градиент.

Вообще говоря, LinearGradientBrush используется для закрашивания области линейным градиентом. Линейный градиент определяет градиент по линии. Конечная точка линии определяется свойствами StartPoint и EndPoint линейного градиента. По умолчанию StartPoint линейного градиента соответствует (0, 0), при этом закрашивается верхний левый угол области, и его EndPoint соответствует (1, 1), при этом закрашивается нижний правый угол области. Как представлено на фиг.15, при использовании значений по умолчанию цвета в результирующем градиенте интерполируются по диагональной траектории. Черная линия, образованная из начальной и конечной точек градиента, была добавлена в данной заявке, чтобы подчеркнуть траекторию интерполирования градиента.

Перечисление ColorInterpolationMode определяет режим интерполирования для цветов в градиенте. Двумя вариантами являются PhysicallyLinearGamma10 и PerceptuallyLinearGamma22.

Это абстрактный базовый класс.

Как описано выше в разделе Changeable, GradientBrush представляет собой сложный тип в отношении Changeable, так как его само свойство GradientStops хранит Changeable. Это означает, что GradientBrush необходимо реализовывать защищенные методы MakeUnchangeableCore() и PropagateEventHandler(), а также CloneCore(), которые реализует подкласс Changeable. Он также может выбрать реализацию ValidateObjectState(), если существуют недействительные комбинации GradientStops, которые, например, составляют коллекцию.

LinearGradient задает кисть линейного градиента вдоль вектора. Отдельные ограничители задают ограничители цветов вдоль этого вектора.

Разметка для LinearGradient допускает спецификацию LinearGradient с двумя ограничителями цветов со смещениями, равными нулю и единице. Если используется вариант «LinearGradient», то задаются начальная точка и конечная точка, соответственно. Если используется «HorizontalGradient», то начальная точка устанавливается на 0,0 и конечная точка устанавливается на 1,0. Если используется «VerticalGradient», то начальная точка устанавливается на 0,0 и конечная точка устанавливается на 0,1. В этих случаях используется MappingMode по умолчанию, которым является RelativeToBoundingBox.

RadialGradient аналогичен в модели программирования линейному градиенту. Однако, тогда как линейный градиент имеет начальную и конечную точку для определения вектора-градиента, радиальный градиент имеет круг вместе с фокальной точкой для определения поведения градиента. Окружность определяет конечную точку градиента - другими словами, ограничитель градиента в 1,0 определяет цвет на окружности круга. Фокальная точка определяет центр градиента. Ограничитель градиента в 0,0 определяет цвет в фокальной точке. На фиг.16 представлен RadialGradient, который (в градациях серого) проходит от белого к серому. Внешняя окружность представляет окружность градиента, тогда как сплошная точка обозначает фокальную точку. У этого градиента SpreadMethod установлен в Pad.

Разметка для RadialGradient допускает спецификацию RadialGradient с двумя ограничителями цвета со смещениями, равными 0 и 1, соответственно. Используется MappingMode по умолчанию, которым является RelativeToBoundingBox, как и по умолчанию радиус равен 0,5:

TileBrush представляет собой абстрактный базовый класс, который содержит логические средства для описания элемента мозаики и средство, посредством которого данный элемент мозаики должен закрашивать область. Подклассы TileBrush содержат содержимое и логически определяют способ закрашивания бесконечной плоскости.

Перечисление Stretch используется для описания того, как ViewBox (исходное координатное пространство) отображается на ViewPort (координатное пространство назначения). Оно используется в TileBrush:

На фиг.18 представлены примеры растягивания. На этих примерах содержимое выравнивается вверху и слева.

Используется перечисление TileMode для описания того, закрашивается ли пространство посредством Tile. TileBrush определяет, где находится базовый Tile (задаваемый при помощи ViewPort). Остальное пространство закрашивается, основываясь на значении TileMode.

На фиг.19 представлены примеры TileMode. Самый верхний и левый элемент мозаики в каждом примере представляет собой базовый элемент мозаики. Эти примеры представляют None, Tile, FlipX, FlipY и FlipXY.

Перечисление VerticalAlignment используется для описания того, как содержимое располагается в контейнере по вертикали:

Перечисление HorizontalAlignment используется для описания того, как содержимое располагается в контейнере по горизонтали.

Свойства TileBrush выбирают прямоугольную часть бесконечной плоскости для элемента мозаики (ViewBox) и описывают прямоугольник назначения (ViewPort), который будет базовым Tile в закрашиваемой области. Остальная область назначения будет закрашиваться, основываясь на свойстве TileMode, которое управляет, дублируется ли исходный элемент мозаики для закрашивания остального пространства:

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

ViewPort определяет расположение, где, в конечном счете, будет нарисовано содержимое, создавая базовый элемент мозаики для этой Brush. Если значением ViewPortUnits является Absolute, то значение ViewPort, как считается, находится в локальном пространстве во время работы прикладной программы. Если, вместо этого значением ViewPortUnits является RelativeToBoundingBox, то тогда значение ViewPort, как считается, находится в координатном пространстве, где 0,0 является верхним/левым углом ограничивающего прямоугольника закрашиваемого объекта, и 1,1 является нижним/правым углом этого же прямоугольника. Например, рассмотрим закрашиваемый RectangleGeometry, который рисуется от 100,100 к 200,200. Тогда, если ViewPortUnits является Absolute, то ViewPort (100,100,100,100) будет описывать всю область содержимого. Если ViewPortUnits является RelativeToBoundingBox, то ViewPort (0,0,1,1) будет описывать всю область содержимого. Если Size в ViewPort пустой и Stretch не равен None, то эта Brush тогда ничего не визуализирует.

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

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

Если ViewBox равен Empty, то он считается неустановленным. Если он не установлен, то тогда рассматриваются ContentUnits. Если ContentUnits равны Absolute, не происходит ни масштабирование, ни смещение, и содержимое рисуется в Viewport без преобразования. Если ContentUnits равны RelativeToBoundingBox, то тогда начало отсчета содержимого выравнивается с Origin ViewPort, и содержимое масштабируется на ширину и высоту ограничивающего прямоугольника объекта.

При закрашивании пространства при помощи TileBrush содержимое отображается в ViewPort, как описано выше, и отсекается до ViewPort. Это образует базовый элемент мозаики для закрашивания, и остальная часть пространства закрашивается, основываясь на TileMode Brush. Если установлен, то применяется преобразование Brush, которое происходит после другого отображения, масштабирования, смещения и т. д.

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

ImageBrush представляет собой TileBrush, имеющую содержимое, заданное при помощи ImageData. Данная Brush может использоваться для закрашивания пространства при помощи Image.

VideoBrush представляет собой TileBrush, содержимое которой задается при помощи VideoData. Данная Brush может использоваться для закрашивания пространства при помощи Video.

NineGridBrush представляет собой Brush, которая всегда закрашивает ограничивающий прямоугольник объекта его изображением содержимого, и растягивание изображения не выполняется исключительно при помощи масштабирования визуального объекта. Источник Image делится на девять прямоугольников при помощи четырех границ (отсюда имя NineGrid). Содержимое изображения в каждой из этих девяти областей масштабируется по 0, 1 или 2 размерам до тех пор, пока они не закрасят ограничивающий прямоугольник объекта. Размеры, по которым масштабируется каждая секция, можно видеть на этом графическом представлении: на фиг.17 представлен принцип NineGrid, увеличиваемой с первого экземпляра 1702 до второго экземпляра 1704, причем четыре типа изображения девяти ячеек сетки, которые определяются границами Top, Left, Bottom и Right. Стрелки в каждом прямоугольнике сетки показывают размер (размеры), по которому это содержимое будет растягиваться, чтобы соответствовать размеру ViewPort.

В дополнение к девяти областям сетки, изображенным выше, существует необязательная «десятая» ячейка сетки. Она принимает форму дополнительного изображения, которое центрировано в ViewPort и которое не масштабируется. Это может использоваться для размещения формы в центре кнопки и т. д. Эта «десятая ячейка сетки» называется глиф и раскрывается при помощи свойства GlyphImageData:

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

Pen представляет собой объект, который принимает Brush и другие параметры, которые описывают, как обвести по контуру пространство/Geometry. Концептуально, Pen описывает, как создать область обведения по контуру из Geometry. Создается новая область, которая основывается на краях Geometry, Thickness у Pen, PenLineJoin, PenLineCap и т. д. Если эта область создана, она закрашивается при помощи Brush.

PenLineCap определяет, как рисуются концы обводимой по контуру линии.

PenDashCap определяет, как рисуются концы каждой черточки в пунктирной, обводимой по контуру линии:

PenLineJoin определяет, как рисуются соединения при обводке по контуру линии:

Класс DashArrays содержит статические свойства, которые обеспечивают доступ к общим, общеизвестным стилям черточек:

Другим объектом кисти, представленным на фиг.13, является объект VisualBrush. VisualBrush представляет собой TileBrush, содержимое которой задается при помощи Visual. Данная Brush может использоваться для создания сложных узоров, или она может использоваться для рисования дополнительных копий содержимого других частей сцены.

Концептуально, VisualBrush обеспечивает способ рисования визуального объекта повторяющимся, мозаичным образом, как закрашивание. Это представлено на фиг.12 при помощи кисти визуального объекта, ссылающейся на визуальный объект (и любые порожденные визуальные объекты), которые задают единичную круглую форму 1220, при этом данной круглой формой закрашивается прямоугольник 1222. Таким образом, объект VisualBrush может ссылаться на визуальный объект для определения того, как рисовать этой кистью, что вводит тип многократного использования для визуальных объектов. Таким образом, программа может использовать произвольные графические «метафайлы» для закрашивания области при помощи кисти или пера. Так как это представляет собой сжатую форму для хранения и использования произвольной графики, она служит графическим ресурсом.

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

ViewPort определяет положение, где содержимое, в конечном счете, будет рисоваться, создавая базовый элемент мозаики для данной Brush. Если значение 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 пустой, то данная Brush ничего не визуализирует.

ViewBox задается в пространстве содержимого. Данный прямоугольник преобразуется так, чтобы соответствовать ViewPort, определенному свойствами Alignment и свойством Stretch. Если Stretch равен None, то тогда к содержимому не применяется масштабирование. Если Stretch равен Fill, то тогда ViewBox масштабируется независимо как по Х, так и по Y, чтобы он был такого же размера, что и ViewPort. Если Stretch равен Uniform или UniformToFill, то логика аналогична, но размеры по Х и по 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 мозаики графики, визуализируемого при помощи различных установок растягивания, включая элемент 1800 мозаики, когда растягивание установлено на «none». Элемент 1802 мозаики представляет собой представление того случая, когда растягивание устанавливается на «Uniform», элемент 1804 мозаики - когда растягивание устанавливается на «UniformToFill», и элемент 1806 мозаики - когда растягивание устанавливается на «Fill».

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

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

При закрашивании пространства при помощи VisualBrush содержимое отображается в ViewPort, как описано выше, и отсекается до ViewPort. Это образует базовый элемент мозаики для закрашивания, и остальная часть пространства закрашивается, основываясь на TileMode Brush. Наконец, если установлено, применяется преобразование Brush - оно происходит после всех других отображений, масштабирований, смещений и т. д.

Перечисление TileMode используется для описания того, закрашивается ли пространство при помощи его Brush и как оно закрашивается. Brush, которая может выкладываться мозаикой, имеет определенный прямоугольник элемента мозаики, и этот элемент мозаики имеет базовое расположение внутри закрашиваемого пространства. Остальная часть пространства закрашивается, основываясь на значении TileMode. На фиг.19 изображено представление примерной графики с различными установками TileMode, включая «None» 1900, «Tile» 1092, «FlipХ» 1904, «FlipY» 1906 и «FlipXY» 1908. Самый верхний левый элемент мозаики в различных примерах графики содержит базовый элемент мозаики.

На фиг.20 представлена VisualBrush Grid, которая определяется для элементов мозаики в VisualBrush. Первая окружность представляет собой простую сетку, и вторая имеет Transform с Skew по размеру х, равному 47. На фиг.21 изображается, как эта сетка закрашивается изображением.

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

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

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

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

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

В большинстве мест в ИПП не принимают непосредственно Matrix, но, вместо этого, используют класс Transform, который поддерживает анимацию.

Заключение

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

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

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

2. Способ по п.1, в котором при модифицировании данных в графе сцены инициализируют новый экземпляр класса визуального объекта.

3. Способ по п.2, в котором при модифицировании данных в графе сцены активируют код для ассоциирования преобразования с визуальным объектом в графе сцены.

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

5. Способ по п.4, дополнительно содержащий этап, на котором возвращают контекст рисования, причем этот контекст рисования обеспечивает механизм для визуализации в визуальном объекте рисования.

6. Способ по п.2, в котором при модифицировании данных в графе сцены активируют код для ассоциирования данных кисти с визуальным объектом в графе сцены.

7. Способ по п.6, в котором данные кисти подразумевают прием данных, соответствующих чистому цвету.

8. Способ по п.6, в котором при приеме данных кисти принимают данные, соответствующие кисти линейного градиента, и коллекцию ограничителей, содержащую по меньшей мере один ограничитель.

9. Способ по п.6, в котором при приеме данных кисти принимают данные, соответствующие кисти радиального градиента.

10. Способ по п.6, в котором при приеме данных кисти принимают данные, соответствующие изображению.

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

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

13. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для представления эллипса в структуре данных графа сцены.

14. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для представления прямоугольника в структуре данных графа сцены.

15. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для представления траектории в структуре данных графа сцены.

16. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для представления линии в структуре данных графа сцены.

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

18. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для преобразования координат визуального объекта в структуре данных графа сцены.

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

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

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

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

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

24. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для помещения данных, соответствующих тексту, в структуру данных графа сцены.

25. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для предоставления контекста рисования в ответ на вызов функции.

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

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

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

29. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для помещения данных анимации в структуру данных графа сцены.

30. Способ по п.29, дополнительно содержащий этап, на котором передают информацию о временной шкале, соответствующую данным анимации, на средство компоновки и анимации.

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

32. Способ по п.1, в котором при модифицировании данных в графе сцены выполняют синтаксический анализ программного кода на высокоуровневом языке разметки графики с получением вызова интерфейса объекта.

33. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для помещения объекта, соответствующего аудио- и/или видеоданным, в структуру данных графа сцены.

34. Способ по п.1, в котором при модифицировании данных в графе сцены активируют код для изменения изменяемого значения объекта в структуре данных графа сцены.