Динамическая архитектура окон

Изобретение относится к графическому интерфейсу пользователя компьютерной операционной системой. Техническим результатом является обеспечение создания администратора рабочего стола, поддерживающего динамическую архитектуру окон с унаследованными приложениями. В способе и системе для визуализации модели комбинированного рабочего стола используют средство управления окнами комбинированного рабочего стола после приема от прикладной программы информации о базовом объекте и объекте контента для одного или нескольких объектов контента, вычерчивают окно в буферной памяти и используют преимущества усовершенствованных графических аппаратных средств и визуальных эффектов для визуализации окон на основе контента, по которому они вычерчены. Рамочная часть каждого окна может быть создана путем затенения пикселей битовой карты в виде матированного стекла на основе контента рабочего стола, поверх которого отображается указанная рамка. Поддержка унаследованных приложений обеспечивается таким образом, что операционная система может вычерчивать и визуализировать окна, созданные унаследованными приложениями, чтобы они смотрелись согласовано с окнами неунаследованных приложений. 3 н. и 18 з.п. ф-лы, 7 ил., 1 табл.

 

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

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

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

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

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

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

Компьютерные операционные системы используют программный уровень, отвечающий за управление объектами пользовательского интерфейса, такими как пиктограммы, меню, курсоры, окна и рабочие столы; за арбитраж событий, поступающих от устройств ввода, таких как мышь и клавиатура; и за предоставление услуг пользовательского интерфейса программным приложениям. Этот программный уровень можно назвать средством управления (администратором) окнами рабочего стола (DWM). Логические средства визуализации, маршрутизация введенных событий и интерфейсы прикладного программирования (API) администратора окон рабочего стола (DWM) в совокупности воплощают политику пользовательского интерфейса, которая, в свою очередь, определяет все возможности пользователя, предоставляемые операционной системой. К настоящему времени основной причиной отсутствия рабочих столов с богатыми визуальными возможностями являются недостатки способов, с помощью которых администраторы DWM управляют работой рабочего стола и визуализируют рабочий стол. В известных вариантах реализации DWM для визуализации рабочего стола используется модель «недействительности», которая развивалась в основном исходя из потребности экономии ресурсов памяти для видео ресурсов и системных ресурсов, а также пропускной способности центрального процессорного устройства (CPU) и блока обработки видеографики (GPU).

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

Преимуществом модели с передачей сообщений о недействительности является экономия памяти, необходимой для отображения на экране дисплея. То есть, для основывающегося на признании недействительности DWM требуется только поддерживать достаточный объем буферной памяти для вычерчивания одного рабочего стола без «запоминания» того, что возможно находится под отображаемым в данный момент контентом. Однако поскольку окна на рабочем столе визуализируются в порядке сверху вниз, такие признаки, как непрямоугольные окна и двухмерная анимация через интерфейс GDI с расширенными возможностями, требуют интенсивных вычислений CPU, включая комплексные зоны, и/или экстенсивной дискретизации поверхности отображения на экране дисплея (из-за чего ограничивается возможность ускорения на основе графических аппаратных средств), тогда как другие признаки, такие как прозрачность, тени, трехмерная графика и усовершенствованные эффекты подсветки, достигаются с очень большим трудом и требуют сверхинтенсивного расхода ресурсов.

Например, администратор окон Microsoft Windows^®XP, известный как USER, служит в качестве основной компоненты подсистемы графического пользовательского интерфейса (известной на сегодня как Win32) с момента появления операционной системы марки Windows^®. USER использует средство двухмерного графического воспроизведения интерфейса графических устройств (GDI) для визуализации отображения. Интерфейс GDI является другой главной субкомпонентой Win32, причем он базируется на технологии визуализации, имеющейся в оригинальной операционной системе марки Windows^®. USER визуализирует каждое окно на дисплее, используя модель с передачей сообщения о недействительности во взаимодействии с зонами отсечения GDI и примитивами двухмерного вычерчивания. Основные действия USER при визуализации рабочего стола включают в себя идентификацию зон дисплея, нуждающихся в визуальном обновлении, и информирование приложений об этой потребности и о местоположении для вычерчивания в соответствии с моделью недействительности для визуализации рабочего стола.

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

Эволюция компьютерных аппаратных средств для видео для средних и младших моделей по большей части стимулировалась графическими услугами, имеющимися в популярных операционных системах. Однако графические услуги, имеющиеся в популярных операционных системах, не претерпели значительных усовершенствований по различным причинам, в том числе из-за необходимости поддерживать совместимость с более старыми прикладными программными средствами и ограниченных возможностей приемлемого по стоимости диапазона аппаратных средств для видео. Однако не так давно трехмерные компьютерные игры реального масштаба времени обогнали операционные системы в качестве основного рыночного стимула для развития розничных аппаратных средств для видео, которые за короткое время достигли исключительного уровня сложности. Теперь пользователям по приемлемой цене доступны возможности трехмерного ускорения на основе аппаратных средств реального масштаба времени. Таким образом, стали легко доступными некогда считавшиеся весьма прогрессивными такие графические аппаратные функции, как ускоренные алгоритмы наложения текстур и подсветки, трехмерные преобразования и возможность непосредственного программирования GPU. В настоящее время обычно только игровые программы и узко специализированные графические приложения активно используют указанные признаки, и для их реализации они должны обходить унаследованный администратор окон Win32 (USER) и GDI.

Другим препятствием при реализации модели компоновки рабочего стола является то, что унаследованные приложения, написанные для использования с DWM на основе модели недействительности, не будут правильно функционировать в среде для компоновки. Это происходит потому, что базовые логические средства визуализации у унаследованного приложения основаны на API DWM модели недействительности из состава операционной системы. То есть, вместо визуализации контента окна в качестве непосредственной реакции на взаимодействие с пользователем или на изменения внутреннего состояния, унаследованное приложение будет выдавать изображение только после приема сообщения о раскраске, созданного либо операционной системой, либо по собственному запросу о недействительности. Самым трудным является разработка средства, с помощью которого DWM компоновки заменит собой унаследованную платформу GUI от имени приложения. Более простые альтернативные варианты состоят в исключении приложения из скомпонованной конфигурации рабочего стола (такой подход известен в данной области техники как «помещение в песочницу») или просто полного отказа от совместимости унаследованного приложения.

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

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

Сущность изобретения

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

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

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

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

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

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

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

фиг.1В - распределение функций и услуг между компонентами в иллюстративном варианте осуществления платформы комбинированного рабочего стола;

фиг.2 - способ компоновки согласно иллюстративному аспекту изобретения;

фиг.3 - окно согласно иллюстративному аспекту изобретения;

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

фиг.5 - окно в рамке из матированного стекла, визуализированное согласно иллюстративному аспекту изобретения;

фиг.6 - окно с динамической архитектурой окна;

фиг.7 - зоны, используемые во время изменения размеров сетки.

Подробное описание изобретения

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

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

Иллюстративная операционная среда

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

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

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

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

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

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

Компьютер 110 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации. Только в качестве примера, на фиг.1 показан накопитель 140 на жестких магнитных дисках, который осуществляет считывание или запись на несъемный, энергонезависимый магнитный носитель; магнитный дисковод 151, который осуществляет считывание или запись на съемный энергонезависимый магнитный диск 152; и оптический дисковод 155, который осуществляет считывание или запись на съемный энергонезависимый оптический диск 156, такой как CD ROM либо другой оптический носитель. Другие съемные/несъемные энергозависимые/энергонезависимые компьютерные носители информации, которые можно использовать в приведенной в качестве примера операционной среде, включают в себя, но не в ограничительном смысле, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельное RAM, твердотельное 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 команды и информацию через устройства ввода, такие как клавиатура 162 и координатно-указательное устройство 161, известное как «мышь», шаровой манипулятор или сенсорный планшет. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую приставку, спутниковую антенну, сканер или т.п. Эти и другие устройства ввода часто подсоединены к блоку 120 обработки данных через интерфейс 160 пользовательского ввода, который соединен с системной шиной, но могут быть подсоединены с помощью других интерфейсных и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). К системной шине 121 через интерфейс, такой как видеоинтерфейс 183, также подсоединен монитор 184 либо устройство отображения другого типа. Компьютер 110 может также включать в себя цифровой преобразователь 185 для использования вместе с монитором 184, чтобы дать возможность пользователю обеспечить ввод с использованием перьевого устройства 186 ввода. Вдобавок к монитору компьютеры могут также включать в себя другие периферийные устройства вывода, такие как громкоговорители 189 и принтер 188, которые могут быть подсоединены через выходной периферийный интерфейс 187.

Компьютер 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. Очевидно, что показанные сетевые соединения являются лишь примерами и что можно использовать другие средства для установления линии связи между компьютерами.

Иллюстративные варианты осуществления

Изобретение может использовать администратор компоновки окон рабочего стола (СDWM) для вычерчивания и поддержки отображения рабочего стола с использованием модели комбинированного рабочего стола, то есть методологии визуализации снизу вверх. СDWM может поддерживать контент в области буферной памяти для обращения в будущем. СDWM компонует рабочий стол, изображая его снизу вверх, начиная с фона рабочего стола и продолжая через перекрывающиеся окна в обратном порядке по Z-координате. При компоновке рабочего стола СDWM может вычерчивать каждое окно, частично на основе контента, в верхней части которого изображается окно, а частично на основе других внешних факторов (например, источника света, отражательных свойств и т.д.). Например, СDWM может использовать альфа-канал текстуры формата AGRB (формат RGB с добавлением информации о прозрачности) для обеспечения прозрачности окна и может избирательно выделять участки контента окна (например, рамку) на основе виртуального источника света.

СDWM может храниться как часть операционной системы 134, 144 либо может храниться независимо от операционной системы, например, в других программных модулях 136, 146. Помимо этого, СDWM может основываться на подсистеме графической компоновки более низкого уровня, называемой здесь унифицированным средством компоновки (UCE), который дополнительно описывается ниже, а также в одновременно рассматриваемой заявке с серийным номером (индекс патентного поверенного 50037.201US01), поданной 23 октября 2003 года, под заголовком «System and Method for a United Composition Engine in a Graphics Processing System», содержание которой целиком включено сюда посредством ссылки. В одном иллюстративном варианте осуществления UCE базируется на технологии Direct3D^® или DirectX^® от Microsoft Corporation of Redmond, Washington, либо использует эту технологию. В альтернативных вариантах осуществления могут быть использованы другие подсистемы графической компоновки, такие как вариации платформы X Window на основе графических средств OpenGL^® от компании Silicon Graphics, Inc. Of Mountain View, California и т.п. UCE позволяет реализовать трехмерную графику и анимацию, прозрачность, тени, эффекты подсветки, отображение рельефа, отображение окружения и другие разнообразные визуальные признаки на рабочем столе.

На фиг.1В показана многокомпонентная архитектура согласно иллюстративному варианту осуществления платформы для компоновки рабочего стола. Администратор 190 компоновки окон рабочего стола (СDWM) может включать в себя интерфейс 190а прикладного программирования, через который прикладные программные средства 191 для компоновки получают услуги СDWM по созданию и управлению окнами и контентом; интерфейс 190b подсистемного программирования, через который унаследованная графическая подсистема 192, организующая окна, посылает уведомления об обновлениях для изменений, воздействующих на переадресованный графический вывод отдельных окон (переадресация графического вывода подробно описана ниже); и администратор 190c объектов UI, который поддерживает упорядоченное по Z-координате хранилище (репозиторий) для объектов UI рабочего стола, таких как окна и связанный с ними контент. Администратор объектов UI может осуществлять связь с администратором 193 тем для поиска ресурсов, атрибутов поведения объекта и параметров визуализации, связанных с темой активного рабочего стола.

Подсистема 192 унаследованного графического пользовательского интерфейса может включать в себя унаследованный администратор 192а окон и унаследованный интерфейс 192b графических устройств. Унаследованный администратор 192а окон обеспечивает управление окнами на основе модели недействительности и предоставляет услуги рабочего стола для программных приложений, разработанных до появления СDWM. Унаследованный интерфейс 192b графических устройств предоставляет услуги двухмерной графики как унаследованным приложениям, так и унаследованному администратору окон. Унаследованный интерфейс графических устройств, основывающийся на модели недействительности для визуализации рабочего стола, может нуждаться в поддержке трехмерных примитивов и преобразований для визуализации на основе аппаратных средств ускорения и возможно сам по себе не может поддерживать прозрачность альфа-канала по пикселям во время операций копирования и пересылки битовой карты. Унаследованный администратор 192а окон вместе с интерфейсом 192b графических устройств продолжает обслуживание для уменьшения расходов на владение для пользователей, которые хотят обновить свою операционную систему без потери способности выполнения своих любимых или важных программных приложений, которые используют модель недействительности. Чтобы обеспечить прозрачную стыковку унаследованных прикладных окон с окнами приложений, осведомленных о компоновке, таким образом, чтобы потери для конечного пользователя оказались небольшими или неощутимыми, может быть предусмотрено активное участие унаследованной подсистемы 192 графического пользовательского интерфейса в процессе компоновки. Действительно, воспринимаемая среда платформы для унаследованных приложений предпочтительно не изменяется, чтобы избежать опасности неустойчивой работы на комбинированном рабочем столе, при этом фундаментальный способ, с помощью которого унаследованные окна визуализируются на рабочем столе, будет коренным образом изменен. Изобретение описывает, каким образом это достигается посредством добавления описанного здесь признака в виде переадресации графического вывода окна.

Унифицированное средство 194 компоновки (UCE) может обслуживать команды визуализации и объединять ресурсы от СDWM через интерфейс 194а программирования. В широком смысле слова роль UCE по отношению к СDWM аналогична роли унаследованного интерфейса 192b графических устройств по отношению к унаследованному администратору 192а окон. Интерфейс 194а программирования UCE обеспечивает СDWM и, в конце концов, приложения абстрактным интерфейсом для широкого диапазона графических услуг. В число этих услуг UCE входит управление ресурсами, инкапсуляция из сценариев с множеством дисплеев и удаленная поддержка рабочего стола.

Внутренний администратор 194b ресурсов может обеспечить арбитраж при конкуренции графических ресурсов между операциями записи СDWM и операциями визуализации. Запросы на обновления ресурсов и на услуги визуализации помещаются в очередь 194 с запросов UCE под компонентой 194а интерфейса программирования. Эти запросы могут обрабатываться асинхронно модулем 194d визуализации с интервалами, соответствующими частоте обновления устройств отображения, установленных в системе. Таким образом, модуль 194d визуализации UCE может выводить из очереди запросы СDWM, обращаться к ресурсам и манипулировать ресурсами, хранящимися в администраторе 194b ресурсов, когда это необходимо, а также формировать и доставлять специализированные для конкретного дисплея команды визуализации в интерфейс 195 трехмерной графики.

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

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

Интерфейс 195 трехмерной графики может включать в себя графическую услугу низкого уровня прямого действия (не имеет состояния в процессе исполнения), такую как Direct3D^®, OpenGL^® или т.п. Назначение интерфейса трехмерной графики может состоять в обеспечении абстрактного интерфейса в отношении признаков конкретной конфигурации графических аппаратных средств. Интерфейс трехмерной графики может обслуживать одно устройство отображения; UCE может анализировать и распределять команды визуализации СDWM среди множества устройств 197 графического вывода в системе с множеством дисплеев через множество драйверов 196 устройств.

Следует заметить, что архитектура компонентов, изображенная на фиг.1В, соответствует иллюстративному варианту осуществления. Эта фигура предназначена для иллюстрации функций, которые может иметь изобретение. Эти функции могут быть распределены между меньшим или большим количеством программных компонент, чем представлено на фигуре, в соответствии с возможностями платформы и требуемым набором признаков. Например, система, которая нуждается в управлении темами, может получать все базовые ресурсы из системы, подобно статическим ресурсам, управляемым самим СDWM, а не от отдельного администратора тем. Платформа, которая позволяет использовать сменные администраторы окон, может заменить интерфейс 190а прикладного программирования в СDWM на сменный интерфейс администратора окон, чтобы обобщить детали комбинированного объекта UI и управления ресурсами. Другим возможным вариантом может быть исключение интерфейса 190b подсистемного программирования, если не требуется совместимость унаследованного приложения. Подкомпоненты UCE 94, показанные на фиг.1В, могут быть выделены в отдельные процессы, свернуты в СDWM или интегрированы в интерфейс трехмерной графики. Таким образом, возможен широкий диапазон конкретных многокомпонентных разработок, каждая из которых способна перекрывать либо весь диапазон функций, содержащихся в изобретении, либо поднабор этих функций.

На фиг.2 показан общий способ выполнения компоновки рабочего стола согласно иллюстративному аспекту изобретения. Этапы с 201 по 205 описывают взаимодействие приложения, осведомленного о компоновке, которое использует интерфейсы API администратора компоновки окон рабочего стола (CDWM) для создания и управления окном, с контентом окна. Этапы 207 и 209 описывают взаимодействие между унаследованными приложениями администратора окон на основе модели недействительности с СDWM для компоновки унаследованного контента окна.

На этапе 201 администратор компоновки окон рабочего стола принимает запросы от приложения, осведомленного о компоновке, для (1) создания комбинированного окна и (2) присоединения объекта контента. Изобретение не сводится к одному объекту контента на окно; приложение может динамически создавать и присоединять к одному окну (а также отсоединять и ликвидировать) любое количество объектов контента через API СDWM, как это дополнительно описано ниже. Объект контента состоит из растровой поверхности заданного размера и формата пикселя, используемых в качестве диффузной текстуры, отображаемой на сетку, определенную приложением или системой, вместе с необязательными дополнительными ресурсами, такими как дополнительные текстуры (карта освещенности, зеркальная карта, карта рельефа/нормальная карта и т.д.), подсветка и программное средство вычисления цвета пикселя (пиксельный шейдер). Формат пикселя диффузной текстуры контента может быть любым из имеющихся форматов, поддерживаемых аппаратными средствами видео, установленными в системе, но в текущем примере это может быть 32-битный формат ARGB. При запросе этого формата приложение может явным образом быть осведомленным о том, что для изменения уровня прозрачности пикселя контента может быть использован альфа(А)-канал, что позволяет таким образом осуществлять точный контроль в отношении объема информации о фоне рабочего стола в соответствии с исходным пикселем при окончательной визуализации. На этапе 203 СDWM назначает блок состояния для окна, к которому он присоединяет объект контента, реализованный СDWM. Этот объект контента распределяет запрошенные ресурсы или присоединяет ресурсы, направленные приложением, а затем размещает эти ресурсы на UCE, обеспечивая возможность доступа по запросам обновления UCE. На этапе 205 приложение уведомляет СDWM о непредусмотренном изменении в окне или в контенте окна. Эти изменения могут воздействовать на любое окно или состояние контента, но для простоты в данном примере показано три общих запроса на обновление: размера контента, положения или масштаба окна или изменения пикселей диффузной текстуры контента.

Процесс компоновки унаследованного окна начинается с инициализации компоновки рабочего стола, причем СDWM 190 доставляет запрос в унаследованную подсистему 192 управления окнами и графикой для переадресации графического вывода каждого унаследованного окна во временное местоположение в памяти (этап 207). Этап 207 можно описать более обобщенно как перевод унаследованного окна и графической подсистемы в «режим компоновки», в котором визуализация каждого отдельного окна перенаправляется в отдельный буфер памяти. В иллюстративном варианте осуществления унаследованная подсистема 192 графического пользовательского интерфейса переадресует вывод графических команд, задействованных в визуализации окна, на поверхность в памяти с битовым отображением, связанную с данным окном. Однако изобретение предусматривает возможность поддержания собственных команд для вычерчивания и связанных с ними параметров, и поддерживает выполнение этих команд в UCE во время процесса компоновки следующего видеокадра для намеченного устройства отображения. Управление этими буферами переадресации (поверхностями или блоками команд для вычерчивания) может осуществляться либо СDWM, либо унаследованным администратором 192а окон, но в иллюстративных целях в этом примере управление ресурсами поверхностей сосредоточено в СDWM. Каждый буфер переадресации либо образует ресурс диффузной текстуры контента для данного окна, либо используется для ее создания. Унаследованному администратору 192а окон нет необходимости вызывать окно СDWM и интерфейсы API для создания контента; канал связи СDWM с унаследованной подсистемой для уведомлений отличается от канала прикладного интерфейса, и СDWM получает атрибуты комбинированных окон (стиль рамки и границы, заголовок и т.д.) и состояние (скрыто/показано, минимизировано/максимизировано и т.д.) из существующих унаследованных свойств окна. На этапе 209 унаследованный администратор 192а окон информирует СDWM 190

о любом изменении, воздействующем на переадресованную текстуру контента окна, которая возможно нуждается в визуальном обновлении.

На этапах 211, 219 и 223 СDWM 190 различает запросы на обновление размеров, положения/масштаба и текстуры на уровне пикселей и действует соответствующим образом. При обновлении размеров (этап 211) СDWM сначала определяет, связан ли кадр с намеченным окном (этап 213). Если кадр связан с данным окном (этап 215), то СDWM определяет подходящий размер и ориентацию кадрового примитива на основе двухмерного или трехмерного экстента, предоставляемого в явном виде приложением, осведомленном о компоновке, или на основе комбинации унаследованной метрики окна и метрики окна СDWM и обновленных размеров переадресованной унаследованной поверхности. Когда размер кадра определен, СDWM вносит соответствующие изменения в информацию о положении в вершинах в сетке рамки и направляет буфер данных вершин в UCE. UCE ставит указание об обновлении сетки и новую информацию о вершинах в очередь для асинхронной обработки. Если окно не имеет рамки, то этап 215 может быть обойден. В случае окон с рамками или без рамок изменения размеров, влияющие на область контента, могут заставить СDWM изменить размеры сетки контента и поставить в очередь к UCE соответствующий запрос и данные обновления сетки (этап 217).

При обновлении положения (включая поворот) или масштаба (этап 219) СDWM определяет параметры нового преобразования и ставит в очередь к UCE запрос на обновление ресурсов для этого преобразования вместе с данными для асинхронной обработки (этап 221). Ресурс состоит по меньшей мере из матрицы преобразования размером четыре на четыре, но может содержать и дополнительные данные для поддержки отфильтрованных преобразований.

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

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

На этапе 227 UCE обрабатывает входящие обновления компоновки и ресурсов от СDWM и на интервалах, синхронизированных с частотой обновления каждого активного графического видеоадаптера, участвующего в компоновке рабочего стола, вновь визуализирует рабочий стол (или соответствующую его часть в многодисплейной конфигурации) во вторичный буфер, соответствующий размеру отображения на экране дисплея. Это выполняется с использованием услуг немедленной визуализации, обеспечиваемых средством трехмерной графики (таким как Direct3D^®), которое, в свою очередь, преобразует рабочий стол в первичную поверхность отображения.

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

На фиг.3 показано окно приложения согласно иллюстративному аспекту изобретения. Окно 301 приложения может включать в себя различные зоны и компоненты. Рамка или базовый контент 303 окна 301 может вмещать дочерний контент, включая кнопки 305 (например, используемые для восстановления, максимизации, минимизации, закрытия окна и т.д.), индикаторную пиктограмму 307, линейки 309 прокрутки, строку 311 меню и текст 313 заголовка окна. Область 315 первичного объекта контента может быть взята из буфера переадресации, полученного от унаследованной подсистемы окон и графического пользовательского интерфейса, либо может быть создана и присоединена к стандартному базовому контенту и визуализирована владеющим ей приложением, осведомленным о компоновке. Специалистам в данной области техники очевидно, что фиг.3 является просто иллюстрацией базовых элементов окон и что можно добавить или альтернативно использовать дополнительные и другие элементы окон. Кроме того, элементы рамки окна могут быть альтернативно представлены приложением, например, для обеспечения отличительного вида и ощущения для прикладной программы. Примером может быть случай, когда прикладная программа обеспечивает элементы линеек прокрутки в виде заказных дочерних объектов контента, так что они выявляют появление и поведение, свойственное данной прикладной программе. Кроме того, приложение может выбрать удаление или изменение положения одного или нескольких типовых элементов рамки, используя

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

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

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

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

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

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

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

На фиг.6 показан пример окна 601 с динамической нестандартной архитектурой, описанной ниже. Окно 601 имеет базовый рамочный объект 603 нестандартной формы (то есть непрямоугольный), рамочные объекты-кнопки 605 нестандартной формы (непрямоугольные), расположенные в нестандартном месте (не в верхнем правом углу окна), обеспечиваемый системой рамочный индикаторный объект-пиктограмма 607 в нестандартном месте (не в верхнем левом углу окна) и рамочный объект-заголовок 613 окна также в нестандартном месте (не выровненный влево на верхней части рамки). На фиг.6 приложение, связанное с окном, задает две области 615а и 615b первичных объектов контента. Область 615а первичных объектов контента имеет правильную (то есть прямоугольную) форму, в то время как область 615b имеет неправильную, непрямоугольную форму. Окно 601 может также включать в себя определенные приложением кадровые объекты-кнопки 617 и 619, обеспечивающие управление навигацией взад и вперед соответственно, например, в контексте просмотра (броузинга).

СDWM может визуализировать базовый участок окна 301 приложения в виде трехмерного (3D) объекта. Трехмерный примитив сетки можно использовать для определения формы объекта в окне (базовая геометрия), первичная диффузная текстура может быть отображена в трехмерную геометрию сетки, и необязательные свойства материала, которые могут включать в себя подсветку, затенение, преломление, размытость и другие параметры и ресурсы специальных эффектов, в том числе вспомогательные текстуры, применяемые в процессе визуализации. Вспомогательные текстуры могут быть использованы в качестве ресурсов для графических эффектов, широко известных среди специалистов в данной области техники, для обеспечения «живого», физически смоделированного взаимодействия с источниками света, курсорами и другими объектами UI в окружении рабочего стола. Таким образом, текстуры могут служить в качестве источника трехмерной нормальной информации для каждого пикселя (нормальное/рельефное отображение), масок подсветки (внешние, диффузные и зеркальные световые фильтры), источников отражения (например, отражение курсора при его зависании над окном), статических карт среды и т.п.

Формат вершин базовой геометрии может, в необязательном порядке, включать в себя 32-битную диффузную цветовую компоненту в формате ARGB и координатные пары {tu_n, tv_n} для отображения вплоть до n текстур в геометрию сетки, как было описано выше. Как достоверно установлено в предшествующем уровне техники, каждое целое приращение tu и tv может определять повторение текстуры в соответствующих размерах. Например, диапазон значений от {0,0, 0,0} (текстура слева, сверху) до {1,0, 1,0} (текстура справа, внизу) представляет единственное повторение по всей сетке, в то время как от {0,0, 0,0} до {6,0, 4,0} определяет шесть повторений по координате x и четыре повторения по координате y.

Экстент контента может быть определен как пара трехмерных точек, задающих ограничивающий экстент {x_left, y_top, z_front, x_right, y_bottom, z_back}, или координаты минимального ограничивающего «ящика» (блока), который содержит базовую геометрию. Это аналогично двухмерному ограничивающему прямоугольнику окна {x_left, y_top, x_right, y_bottom}. Триплет {x_left-x_right, y_top-y_bottom, z_front-z_back} определяет ширину, высоту и глубину экстента контента. Экстент вычисляется и управляется системой и представляет размер и локальное положение контента.

Если размеры объекта в окне можно изменять, то манипулирование экстентом базового контента является тем средством, с помощью которого СDWM может изменять размеры окна. Чтобы сохранить контуры краев и углов, положение каждой вершины в сетке с изменяемым размером нельзя просто масштабировать применительно к новому экстенту. Для обеспечения возможности точного управления процессом изменения размеров сетки, приложением может быть задана заранее определенная функция фильтра положения вершин вместе с применимыми параметрами во время создания окна либо выбрана СDWM по умолчанию. Роль функции фильтра для изменения размеров вершин состоит в определении того, каким образом ведет себя каждая вершина в намеченной сетке при изменении ее ограничивающего экстента. Каждая функция фильтра должна определять для каждой элементарной вершины направление и величину смещения по каждому измерению (x, y, z).

Простейшая функция фильтра определяет направление (положительное или отрицательное) и величину (масштабированную относительно нового экстента или смещенную на величину, равную величине одной из шести поверхностей ограничивающего блока сетки в трехмерном пространстве). То, как ведет себя каждая вершина при операции изменения размеров, может быть описано в отношении каждой вершины и каждого измерения в виде характеристики, связанной с самой вершиной, или может быть определено для сетки в целом в геометрических терминах. Примером последнего подхода является пара векторов {mx_left, my_top, mz_front, mx_right, my_bottom, mz_back}, определяющих шесть плоскостей полей, задающих размеры, каждая из которых связана с поверхностью ограничивающего блока сетки, что приводит к эффективному разделению объема ограничивающего блока на 27 кубических подобластей. Значения полей, задающих размеры, могут оставаться постоянными независимо от размера сетки, либо могут вычисляться на основе начального размера ограничивающего блока. При выполнении операции произвольного изменения размера сетки вершины, появляющиеся в верхней левой передней кубической подобласти (ограниченной {x_left, y_top, z_front, mx_left, my_top, mz_front}), смещены на одну и ту же величину и в одном и том же направлении, что и верхний левый передний угол ограничивающего экстента. Вершины, появляющиеся в кубической подобласти по самому центру (ограниченной набором {mx_left, my_top, mz_front, mx_right, my_bottom, mz_back}), масштабируются относительно нового экстента этой подобласти. Вершины, появляющиеся в передней центральной кубической подобласти, масштабируются относительно нового экстента подобласти по координате x и y, но смещаются на ту же величину и в том же направлении, что и передняя ограничивающая Z-плоскость сетки.

Для облегчения понимания вышеописанного принципа на фиг.7 показан пример операции изменения размеров сетки в двухмерном пространстве. Окно 701 ограничено углами с радиусом 707 закругления угла. Если при операции изменения размеров окна просто масштабируется сетка, на которой базируется окно, радиус закругления угла будет масштабироваться вместе с сеткой. Однако, если радиус закругления угла масштабируется, то радиус закругленных углов может стать слишком большим или слишком малым, что снижает уровень восприятия пользователя и полезность пользовательского интерфейса. Таким образом, при изменении размеров окна 701 предпочтительно, чтобы радиус закругления угла не изменялся. Для предотвращения масштабирования радиуса закругления угла сетка может быть разделена на три сегмента по каждой координате (x, y, z, по мере использования). Таким образом, в настоящем примере окно делится на 9 квадрантов 703а-i. В трехмерном пространстве окно может быть разделено на 27 зон. Каждая координата может быть поделена на равные или неравные части, что позволяет иметь зоны одинакового размера или неодинакового размера. В случае зон с неодинаковыми размерами зоны, ограниченные ограничивающим блоком, могут быть выполнены настолько малыми, насколько это необходимо для охвата материала, так что они не должны быть масштабированы.

В ходе операции изменения размеров окна квадранты смещаются по каждому измерению, по которому квадрант ограничен ограничивающим блоком, и масштабируются по каждому измерению, по которому квадрант ограничен делителем 705а-d зоны. Например, зоны 703а, 703с, 703g и 703i ограничены ограничивающим блоком по меньшей мере с одной стороны по координатам X и Y, так что вершины сетки в зонах 703а, 703с, 703g и 703i сохраняют одинаковый сдвиг относительно ограничивающего блока при изменении размеров окна. Зоны 703b и 703h ограничены ограничивающим блоком по меньшей мере с одной стороны по координате Y (вертикаль), но ограничены только делителями 705 зон по координате X (горизонталь). Таким образом, вершины в зонах 703b и 703h сохраняют свои сдвиги по координате Y, но масштабируются по координате X. Зоны 703d и 703f ограничены ограничивающим блоком по меньшей мере с одной стороны по координате X (горизонталь), но ограничены только делителями 705 зон по координате Y (вертикаль). Таким образом, вершины сетки в зонах 703d и 703f сохраняют свои сдвиги по координате X, но при этом масштабируются по координате Y. Зона 703e ограничена разделительными линиями 705 как по координате X, так и по координате Y, так что вершины сетки, попадающие в зону 703e, будут масштабированы как по координате X, так и по координате Y. Специалистам в данной области техники очевидно, что этот алгоритм можно распространить на трехмерные приложения, включив координату Z, как описано в предыдущих параграфах.

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

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

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

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

Окружающий цвет имитирует свет, падающий на поверхность объекта со всех направлений. Как и свойство материала, применимое к любому объекту контента UI, управляемому СDWM, интенсивность окружающего цвета определяет относительное количество внешнего света, контактирующего с поверхностью объекта, а для задания окружающего цвета и прозрачности может быть использовано 32-битное значение ARGB. В одном иллюстративном варианте осуществления интенсивность окружающего цвета может лежать в диапазоне от 0,0 (нулевой окружающий свет, дающий равномерное черное представление объекта) до 1,0 (максимальная интенсивность заданного цвета, равномерно распределенного по объекту). Воздействие интенсивности окружающего цвета при белом цвете позволяет регулировать общую яркость объекта.

Интенсивность диффузного цвета определяет количество направленного света, рассеиваемого во всех направлениях после контакта с поверхностью объекта. Сам свет обеспечивается одним или несколькими направленными источниками либо кубической световой картой. Как свойство материала, применимое к любому объекту контента UI, управляемому СDWM, диффузный цвет может быть задан 32-битным значением ARGB, которое задает цвет, где альфа-компонента задает прозрачность диффузно отраженного света. Значение интенсивности диффузного цвета лежит в диапазоне от 0,0 (свет вообще диффузно не отражается, что дает равномерное черное представление объекта) до 1,0 (весь свет отражается диффузно, что дает затененное представление объекта в соответствии со значением диффузного цвета). Поверхности литер будут появляться в более реальном виде при моделировании таким образом, что сумма значений интенсивности окружающего цвета и диффузного цвета приближается к 1,0.

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

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

Коэффициент преломления каждого объекта определяет угол пропускания проходящего через него света. Можно использовать закон Снеллиуса: n₁sinθ₁=n₂sinθ₂, где n₁ и n₂ - коэффициенты преломления сред 1 и 2, а θ₁ и θ₂ - углы падения и пропускания света соответственно относительно нормали к поверхности. Следовательно, если среда 1 представляет окружение рабочего стола с присвоенным коэффициентом преломления, равным 1,0 (нет преломления), а среда 2 является базовым объектом окна, то угол преломления определяется как θ_obj=sin^-1(sinθ_env/n_obj). В приведенной ниже таблице 1 показаны известные значения коэффициентов преломления для различных сред, которые могут быть смоделированы.

Таблица 1
Среда	Коэффициент преломления
Вакуум	1,00
Лед	1,31
Вода	1,33
Стекло	обычно от 1,50 до 1,75
Алмаз	2,42

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

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

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

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

Таким образом, администраторы DWM модели недействительности и администраторы DWM модели компоновки полагаются на разную информацию для отображения рабочего стола. Например, в DWM модели недействительности, поскольку такой DWM не хранит копию всей поверхности каждого окна на рабочем столе, DWM должен связаться с приложением для обновления контента во время изменения размеров и повторных отображений. Аналогичным образом, приложение ожидает, что ему не будет нужно обновлять свой контент, если не будет запроса на это со стороны DWM (конечно, если контент не обновляется в результате ввода от пользователя). Если приложение действительно нуждается в независимом обновлении собственного контента, оно просит DWM признать недействительным участок собственного окна, ожидая приема от DWM запроса на раскраску, соответствующую недействительной зоне. Поскольку в случае скомпонованного рабочего стола СDWM поддерживает достаточный объем информации для вычерчивания каждого окна во всей его полноте, СDWM не нуждается в посылке сообщений о раскраске окон при событиях, типа описанных выше. Это, в свою очередь, исключает шаг признания недействительности; приложение просто нуждается в его повторном вычерчивании или вычерчивании его части, как это указывают внутренние события.

Из-за указанных фундаментальных отличий каждый администратор DWM и/или СDWM имеет уникальный набор интерфейсов API, посредством которых прикладные программы ожидают осуществлять связь с DWM для обеспечения обновления контента окна. В результате приложение, исходно запрограммированное для использования с DWM модели недействительности, то есть приложение, которое полагается на сообщения о раскраске для визуализации своего контента, не обязательно будет работать с СDWM модели компоновки. Таким образом, если обратиться к фиг.4, то из нее следует, что СDWM может обеспечить поддержку приложений, исходно разработанных для использования в DWM модели недействительности. Эти приложения называются здесь унаследованными приложениями, а обратно совместимая поддержка называется здесь унаследованной поддержкой. Унаследованные интерфейсы API относятся к интерфейсам API для использования с прежней версией операционной системы, которая использовала DWM модели недействительности, с которым совместимо унаследованное приложение. Унаследованные интерфейсы API 192b (фиг.1В) дают возможность приложению осуществлять связь с DWM модели недействительности (унаследованным DWM) 192а. Унаследованный DWM может использовать отдельный элемент унаследованного API для обработки различных унаследованных уведомлений от имени приложения для СDWM, чтобы пересылать в СDWM информацию о соответствующем состоянии и выполнять преобразования между унаследованным координатным пространством и координатным пространством СDWM для ввода и фокусировки определений. Унаследованный DWM может быть модифицирован для переадресации данных в СDWM, как описывается ниже.

На фиг.4 показана часть способа компоновки окон согласно иллюстративному аспекту изобретения. Этапы 401-409 представляют начальную визуализацию контента, связанного с окном унаследованного приложения, исходную поверхность (или набор, если для создания поверхности требуются команды) визуализации которого получают от унаследованного администратора окон 192а (фиг.1В). Этапы 411-419 показывают визуализацию контента окна, созданного прикладной программой, которая осведомлена о компоновке.

На этапе 401 СDWM принимает начальное уведомление об обновлении для первичного контента окна от унаследованного администратора окон в результате того, что унаследованное приложение вызывает унаследованные интерфейсы API 192b для вычерчивания окна на рабочем столе согласно модели недействительности, для которой было разработано данное приложение. Например, Microsoft^®Word^®XP может вызвать унаследованные API, так что унаследованный DWM 192а будет отображать текст, введенный пользователем. На этапе 403 СDWM извлекает из администратора тем используемую по умолчанию сетку контента. На этапе 405 СDWM извлекает (или создает) поверхность переадресации из унаследованного администратора окон. Эта поверхность может быть использована в качестве диффузной текстуры контента. На этапе 407 СDWM обеспечивает, чтобы поддерживались только требуемые области унаследованной текстуры, так чтобы области, содержащие унаследованную рамку окна, границу и/или заголовок, не визуализировались. Один возможный способ выполнить это целесообразным образом состоит в преобразовании координат сетки, отображающих текстуру, таким образом, что на ограничивающие по x и y экстенты сетки отображается только требуемая область. На этапе 409 СDWM извлекает используемые по умолчанию свойства материала для данного контента. В результате собираются ресурсы и параметры, необходимые для визуализации унаследованного контента.

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

На этапе 413 СDWM определяет, была ли задана заказная сетка контента, и если нет, то извлекает используемую по умолчанию сетку из администратора тем (этап 403). На этапе 415 СDWM определяет, была ли задана заказная текстура, и если нет, то извлекает используемую по умолчанию текстуру из администратора тем. На этапе 417 СDWM определяет, были ли заданы приложением заказные свойства материала, и если нет, то извлекает используемый по умолчанию набор свойств материала из администратора тем. В результате собираются ресурсы и параметры, необходимые для визуализации заказного контента.

На этапе 419 СDWM через интерфейс программирования UCE собирает блок команд визуализации для визуализации контента со ссылками на соответствующую сетку, текстуру и свойства материала. Блок команд визуализации ставится в очередь на выполнение UCE. Блок команд выполняется моделью визуализации UCE по истечении интервала обрабатываемого обновления намеченного устройства (устройств).

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Система обработки данных по п.1, в которой память хранит для по меньшей мере одного дочернего объекта контента геометрию контента и поверхность контента.

8. Система обработки данных по п.7, в которой поверхность контента содержит текстуру AGRB.

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

10. Способ по п.9, в котором отображение основано на базовых полях контента, базовом экстенте и базовом материале.

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

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

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

14. Способ по п.9, в котором отображение основано на свойствах базового материала, содержащих диффузную текстуру и текстуру рельефа.

15. Способ по п.9, в котором отображение основано на геометрии контента и поверхности контента для каждого дочернего объекта контента.

16. Способ по п.15, в котором отображение основано на свойствах поверхности контента, содержащих текстуру AGRB для каждого первичного объекта контента.

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

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

19. Способ по п.18, в котором зоны имеют одинаковые размеры.

20. Способ по п.18, в котором зоны имеют неодинаковые размеры.

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