Патент на изобретение №2392655

(54) НАНЕСЕНИЕ ЧЕРНИЛ В РЕАЛЬНОМ ВРЕМЕНИ

(57) Реферат:

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

Информация о родственных заявках

Настоящая заявка притязает на приоритет заявки США 0/513591, поданной 24 октября 2003 г., озаглавленной «Tablet Platform Controls and APIs» (Элементы управления и интерфейс прикладного программирования (ИПП) планшетной платформы), содержимое которой специально включено в данный документ посредством ссылки.

Уровень техники изобретения

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

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

Уровень техники

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

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

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

Раскрытие изобретения

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

Эти и другие аспекты рассматриваются в отношении фигур и относящегося к ним описания.

Краткое описание чертежей

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

на фиг.1В-1М изображена вычислительная среда общего назначения, поддерживающая один или несколько аспектов настоящего изобретения.

На фиг.2 изображен дисплей для основанной на стило системы ввода согласно аспектам настоящего изобретения.

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

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

На фиг.5 изображен режим объекта, который может поддерживать аспекты настоящего изобретения.

На фиг.6 изображена система для манипулирования электронными чернилами согласно аспектам настоящего изобретения.

На фиг.7 изображена система для манипулирования электронными чернилами согласно аспектам настоящего изобретения.

На фиг.8А и 8В изображены различные подходы для использования входной очереди и выходной очереди согласно аспектам настоящего изобретения.

На фиг.9 и 10 изображены способы создания и использования систем для манипулирования чернилами согласно аспектам настоящего изобретения.

На фиг.11 изображена система с протоколом для предупреждения объекта сбора чернил согласно аспектам настоящего изобретения.

На фиг.12 изображена система с дополнительной очередью согласно аспектам настоящего изобретения.

На фиг.13 изображена система с разделенными компонентами стило реального времени согласно аспектам настоящего изобретения.

На фиг.14 показано, как глубоко распознаватель жестов может искать жесты согласно аспектам настоящего изобретения.

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

На фиг.16 изображен управляемый и неуправляемый код согласно аспектам настоящего изобретения.

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

На фиг.18 и 19 изображены различные системы для манипулирования данными пера согласно аспектам настоящего изобретения.

На фиг.20 изображена очередь согласно аспектам настоящего изобретения.

Осуществление изобретения

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

Данный документ разделен на разделы, чтобы оказать помощь читателю. Данные разделы включают в себя: Характеристики чернил, Термины, Вычислительная среда общего назначения, Обзор нанесения чернил в реальном времени, Объектная модель, Динамическая визуализация и влажные чернила, Распознавание жестов, Синхронные и асинхронные процессы, Каскадирование, Модификация коллекции динамически подключаемых модулей, Распространение ошибок, Управляемые/неуправляемые иллюстрации, Наборы и потоки данных, Синхронизация данных и Интерфейсы прикладного программирования.

Характеристики чернил

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

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

Термины

Вычислительная среда общего назначения

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

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

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

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

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

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

Компьютер 110 также может включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые носители данных компьютера. Только в качестве примера, на фиг.1А изображен накопитель 141 на жестких дисках, который считывает или записывает на несъемные энергонезависимые магнитные носители, накопитель 151 на магнитных дисках, который считывает или записывает на съемный энергонезависимый магнитный диск 152, и накопитель 155 на оптических дисках, который считывает или записывает на съемный энергонезависимый оптический диск 156, такой как компакт-диск или другой оптический носитель. Другие съемные/несъемные, энергозависимые/энергонезависимые носители данных компьютера, которые могут использоваться в примерной операционной среде, включают в себя, но не ограничиваются ими, кассеты с магнитной лентой, карты флэш-памяти, цифровые многофункциональные диски, цифровую видеоленту, твердотельное ОЗУ, твердотельное ПЗУ и т.п. Накопитель 141 на жестких дисках обычно подсоединяется к системной шине 121 при помощи интерфейса несъемной памяти, такого как интерфейс 140, и накопитель 151 на магнитных дисках и накопитель 155 на оптических дисках обычно подсоединяются к системной шине 121 при помощи интерфейса съемной памяти, такого как интерфейс 150.

Накопители и связанные с ними носители данных компьютера, описанные выше и изображенные на фиг.1А, обеспечивают хранение считываемых компьютером инструкций, структур данных, программных модулей и других данных для компьютера 110. На фиг.1А, например, накопитель 141 на жестких дисках изображен как хранящий операционную систему 144, программы 145 приложений, другие программные модули 146 и программные данные 147. Отметьте, что данные компоненты могут быть или теми же самыми или могут быть отличными от операционной системы 134, программ 135 приложений, других программных модулей 136 и программных данных 137. Операционной системе 144, программам 145 приложений, другим программным модулям 146 и программным данным 147 присвоены другие позиции в данном документе для иллюстрации того, что, как минимум, они представляют собой разные копии. Пользователь может вводить команды и информацию в компьютер 110 при помощи устройств ввода, таких как цифровая камера 163, клавиатура 162 и указательное устройство 161, обычно упоминаемое как мышь, шаровой указатель или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровой планшет, антенну спутниковой связи, сканер и т.п. Эти и другие устройства ввода часто подключаются к блоку 120 обработки при помощи интерфейса 160 ввода пользователем, который подсоединяется к системной шине 121, но могут подключаться при помощи других интерфейсов и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (УПШ). Монитор 191 или устройство отображения другого типа также подключается к системной шине 121 при помощи интерфейса, такого как видеоинтерфейс 190. В дополнение к монитору компьютеры также могут включать в себя другие периферийные устройства вывода, такие как громкоговорители 197 и принтер 196, которые могут подключаться при помощи периферийного интерфейса 195 вывода.

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

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

Понятно, что показанные сетевые подключения являются примерными и могут использоваться другие средства установления линии связи между компьютерами. Предполагается существование любых из многочисленных общеизвестных протоколов, таких как протокол управления передачей/протокол Интернета (ПУП/ПИ), Эзернет, протокол передачи файлов (ППФ), протокол передачи гипертекста (ППГТ) и т.п., и система может работать в конфигурации клиент-сервер, позволяющей пользователю извлекать веб-страницы с веб-сервера. Могут использоваться любые из многочисленных обычных веб-браузеров для отображения и манипулирования данными на веб-страницах.

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

Теоретически, интерфейс программирования может рассматриваться, в общем, как показано на фиг.1В или фиг.1С. На фиг.1В изображен интерфейс Interface1 в виде канала, по которому происходит передача первого и второго сегментов кода. На фиг.1С изображен интерфейс, содержащий объекты I1 и I2 интерфейса (которые могут быть или могут не быть частью первого и второго сегментов кода), которые дают возможность первому и второму сегментам кода системы передаваться при помощи носителя М. С учетом фиг.1С можно рассматривать объекты I1 и I2 интерфейса как отдельные интерфейсы одной и той же системы, и также можно считать, что объекты I1 и I2 плюс носитель М составляют интерфейс. Хотя на фиг.1В и 1С показан двунаправленный поток и интерфейсы на каждой стороне потока, определенные реализации могут иметь поток информации только в одном направлении (или отсутствие потока информации, как описано ниже) или могут иметь объект интерфейса только на одной стороне. В качестве примера, и не ограничения, термины, такие как интерфейс прикладного программирования (ИПП), точка входа, метод, функция, подпрограмма, удаленный вызов процедуры и интерфейс модели компонентных объектов (МКО), охватываются определением интерфейса программирования.

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

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

А. Разложение на элементарные операции

Передача между одним сегментом кода и другим может осуществляться косвенно разбиением передачи на множество дискретных передач. Это схематически описывается на фиг.1D и 1Е. Как показано, некоторые интерфейсы могут описываться на языке делимых наборов функциональных возможностей. Таким образом, функциональные возможности по фиг.1В и 1С могут быть разложены на элементарные операции для достижения такого же результата, точно так же как можно математически получить 24, 2 умножив на 2, умножив на 3, умножив на 2. Следовательно, как изображено на фиг.1D, функция, представляемая интерфейсом Interface1, может быть разделена для преобразования передачи интерфейса на множества интерфейсов Interface1A, Interface1B, Interface1C и т.д., в то же время достигая такого же результата. Как изображено на фиг.1Е, функция, представляемая интерфейсом I1, может быть разделена на множество интерфейсов I1a, I1b, I1c и т.д., в то же время достигая такого же результата. Аналогично, интерфейс I2 второго сегмента кода, который принимает информацию от первого сегмента кода, может быть разложен на множество интерфейсов I2a, I2b, I2c и т.д. При разложении на элементарные операции количество интерфейсов, включенных в 1-й сегмент кода, необязательно совпадает с количеством интерфейсов, включенных во 2-й сегмент кода. В обоих случаях по фиг.1D и 1Е функциональная сущность интерфейсов Interface1 и I1 остается такой же, что и на фиг.1В и 1С соответственно. Разложение на элементарные операции интерфейсов также может подчиняться ассоциативным, коммутативным и другим математическим свойствам, так что разложение на элементарные операции может быть трудным для распознавания. Например, порядок операций может не иметь значения, и, следовательно, функция, выполняемая интерфейсом, может выполняться задолго до достижения интерфейса, другой частью кода или интерфейсом или выполняться отдельным компонентом системы. Кроме того, для специалиста в области программирования может быть понятно, что существует множество путей выполнения различных вызовов функции, которые достигают одинакового результата.

В. Переопределение

В некоторых случаях можно проигнорировать, добавить или переопределить определенные аспекты (например, параметры) интерфейса программирования, в то же время все же достигая предполагаемого результата. Это изображено на фиг.1F и 1G. Например, предположим, что интерфейс Interface1 по фиг.1В включает в себя вызов функции Square (ввод, точность, вывод), вызов, который включает в себя три параметра, ввод, точность и вывод, и которая вызывается из 1-го сегмента кода для 2-го сегмента кода. Если средний параметр точности не имеет значения в данном сценарии, как показано на фиг.1F, он может быть просто проигнорирован или даже заменен на не имеющий смысла (в данной ситуации) параметр. Также можно добавить дополнительный, не имеющий смысла параметр. В любом случае могут быть достигнуты функциональные возможности возведения в квадрат, поскольку возвращается вывод после возведения в квадрат ввода вторым сегментом кода. Точность вполне может быть значащим параметром для некоторой части по течению потока данных или другой части вычислительной системы; однако, если очевидно, что точность является необязательной для ограниченного назначения вычисления квадрата, она может быть заменена или проигнорирована. Например, вместо передачи действительного значения точности может быть передано не имеющее смысла значение, такое как день рождения, без неблагоприятного влияния на результат. Аналогично, как показано на фиг.1G, интерфейс I1 заменяется на интерфейс I1′, переопределенный для игнорирования или добавления параметров к интерфейсу. Интерфейс I2 может быть аналогично переопределен как интерфейс I2′, переопределенный для игнорирования необязательных параметров или параметров, которые могут быть обработаны где-то в другом месте. Вопрос в данном случае заключается в том, что в некоторых случаях интерфейс программирования может включать в себя аспекты, такие как параметры, которые не являются необходимыми для некоторых целей, и поэтому их можно проигнорировать, или переопределить, или обработать где-то еще для других целей.

С. Встроенное кодирование

Также может быть возможным объединение некоторых или всех функциональных возможностей двух отдельных модулей кода, так что «интерфейс» между ними изменяет форму. Например, функциональные возможности фиг.1В и 1С могут быть преобразованы в функциональные возможности фиг.1Н и 1I соответственно. На фиг.1Н предыдущие 1-й и 2-й сегменты кода на фиг.1В объединяются в модуль, содержащий оба из них. В данном случае сегменты кода могут все же сообщаться друг с другом, но интерфейс может быть предназначен для формы, которая более подходит для единственного модуля. Таким образом, например, формальные операторы Call и Return больше могут не являться необходимыми, но аналогичная обработка или отклик(и), согласующийся с интерфейсом Interface1, все же может быть в действии. Аналогично, как показано на фиг.1I, часть интерфейса (или весь интерфейс) I2 с фиг.1С может быть переписан внутрь интерфейса I1, образуя интерфейс I1. Как показано, интерфейс I2 делится на I2a и I2b, и часть I2a интерфейса была закодирована внутрь интерфейса I1, образуя интерфейс I1. Для конкретного примера рассмотрим, что интерфейс I1 с фиг.1С выполняет вызов функции square (ввод, вывод), которая принимается интерфейсом I2, который после обработки значения, переданного при помощи ввода (для вычисления квадрата ввода) при помощи второго сегмента кода, передает обратно возведенный в квадрат результат с выводом. В таком случае обработка, выполняемая вторым сегментом кода (возведение в квадрат ввода), может быть выполнена первым сегментом кода без обращения к интерфейсу.

D. Разъединение

Передача между одним сегментом кода и другим может выполняться косвенно посредством разбиения передачи на множество дискретных передач. Это схематически изображается на фиг.1J и 1К. Как показано на фиг.1J, предусматривается одна или несколько частей кода (Интерфейс(ы) разъединения, так как они разъединяют функциональные возможности и/или функции интерфейса от исходного интерфейса) для преобразования передач на первом интерфейсе Interface1, чтобы они соответствовали другому интерфейсу, в данном случае интерфейсам Interface2A, Interface2B и Interface2C. Это может быть выполнено, например, там, где имеется установленная база приложений, предназначенных для выполнения передач, например, с операционной системой по протоколу Interface1, но затем операционная система переходит на использование другого интерфейса, в данном случае интерфейсов Interface2A, Interface2B и Interface 2C. Вопрос заключается в том, что изменяется исходный интерфейс, используемый 2-м сегментом кода, так что он больше не является совместимым с интерфейсом, используемым 1-м сегментом кода, и поэтому используется промежуточный, чтобы сделать старый и новый интерфейсы совместимыми. Аналогично, как показано на фиг.1К, третий сегмент кода может быть введен при помощи интерфейса DI1 разъединения для приема передач от интерфейса I1 и при помощи интерфейса DI2 разъединения для передачи функциональных возможностей интерфейса, например, интерфейсам I2a и I2b, перестроенным для работы с DI2, но чтобы получать такой же функциональный результат. Аналогично, DI1 и DI2 могут работать вместе для конвертирования функциональных возможностей интерфейсов I1 и I2 по фиг.1С новой операционной системе, в то же время обеспечивая такой же или подобный функциональный результат.

Е. Перезапись

Еще другим возможным вариантом является динамическая перезапись кода для замены функциональных возможностей интерфейса на что-то еще, но который достигает такого же общего результата. Например, им может быть система, в которой сегмент кода, представленный на промежуточном языке (например, промежуточный язык компании Microsoft Corporation, Java ByteCode и т.д.), подается на оперативный компилятор или интерпретатор в среде выполнения (такой как та, которая предоставляется инфраструктурой .NET, средой выполнения языка Java или другими подобными средами типа выполнения программ). Оперативный компилятор может записываться для того, чтобы динамически преобразовывать передачи от 1-го сегмента кода на 2-й сегмент кода, т.е. согласовывать их с другим интерфейсом, который может потребоваться для 2-го сегмента кода (или исходного, или другого 2-го сегмента кода). Это изображено на фиг.1L и 1М. Как показано на фиг.1L, данный подход аналогичен сценарию разъединения, описанному выше. Это может быть сделано, например, там, где установленная база приложений предназначена для передачи данных операционной системе в соответствии с протоколом Interface1, но затем операционная система переходит на использование другого интерфейса. Оперативный компилятор может использоваться для согласования передач «на лету» от приложений с установленной базой на новый интерфейс операционной системы. Как изображено на фиг.1М, данный подход динамической перезаписи интерфейса(ов) может также применяться для динамического разложения на элементарные операции или изменения иным образом интерфейса(ов).

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

На фиг.2 изображен иллюстративный планшетный ПК 201, который может использоваться согласно различным аспектам настоящего изобретения. Любые или все отличительные признаки, подсистемы и функции в системе по фиг.1 могут быть включены в компьютер по фиг.2. Планшетный ПК 201 включает в себя большую поверхность 202 дисплея, например, преобразующий в цифровую форму дисплей с плоским экраном, предпочтительно экран жидкокристаллического дисплея (ЖКД), на котором отображается множество окон 203. Используя стило 204, пользователь может выбирать, выделять и/или записывать на преобразующей в цифровую форму поверхности 202 дисплея. Примеры подходящих преобразующих в цифровую форму поверхностей 202 дисплея включают в себя электромагнитные перьевые дигитайзеры, такие как перьевые дигитайзеры компаний Mutoh или Wacom. Также могут использоваться другие типы перьевых дигитайзеров, например, оптические дигитайзеры. Планшетный ПК 201 интерпретирует жесты, сделанные с использованием стило 204, для манипулирования данными, ввода текста, создания рисунков и/или выполнения обычных задач компьютерного приложения, таких как электронные таблицы, программы по обработке текста и т.п.

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

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

Обзор нанесения чернил в реальном времени

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

На фиг.3 изображена иллюстративная система для манипулирования электронными чернилами согласно аспектам настоящего изобретения. Менеджер ввода принимает чернила в менеджере 301 ввода. В данной области техники существуют различные менеджеры ввода, включающие в себя перья и графические планшеты, планшеты компании Wacom и т.п. Существование данных чернил упоминается как событие 302 ввода стило. Затем событие 302 ввода стило манипулируется сборщиком 303 чернил. Объект 303 сбора чернил выполняет начальное манипулирование информацией от менеджера 301 ввода. Затем система динамически визуализирует чернила 304 для вывода на дисплей 305. Другие компоненты могут выполнять более полную обработку чернил. Например, штрих может добавляться к существующему объекту 306 чернил (или может создавать новый объект чернил для включения в него штриха чернил) и может ассоциировать принятые чернила (упоминаемые как данные) с одним или несколькими свойствами. Это показано компонентом со свойствами 307 объекта чернил. Объект чернил может затем быть перерисован (если требуется сглаживание) 308 для отображения на дисплее 305.

На фиг.4 изображен альтернативный подход к системе по фиг.3. Фиг.4 включает в себя внутренний источник 401 ввода стило, менеджер 402 ввода (который может иметь или может не иметь входную очередь), объект 403 сбора чернил и элемент со свойством 405 объекта чернил, объект 404 нанесения чернил в реальном времени и дисплей 406.

Могут манипулироваться два типа наборов вводов: данные, происходящие в результате контакта между стило и дигитайзером, и данные, происходящие в результате движения, выполняемого над дигитайзером. Движения, выполняемые над дигитайзером, при которых не происходит касание дигитайзера, упоминаются как вводы «стило в воздухе». Внутренний источник ввода стило разделяет два набора вводов и направляет их соответствующим образом. В нижеследующем перечисляются различные действия, которые происходят на фиг.4:

А) Событие ввода стило в воздухе добавляется во входную очередь менеджера 402 ввода.

В) Менеджер 402 ввода осуществляет диспетчеризацию ввода стило в воздухе на сбор 403 чернил.

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

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

Е) События «опускания» стило принимаются и посылаются на объект 405 нанесения чернил в реальном времени.

F) Объект 405 нанесения чернил в реальном времени рисует точки, когда они принимаются. Это может упоминаться как динамическая визуализация.

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

Н) Штрих собирается и затем добавляется к объекту чернил.

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

J) Чернила визуализируются, после того как будет завершено нанесение всех чернил.

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

Подход по фиг.4 предусматривает то, что многотредовая осведомленность локализуется в очереди менеджера ввода и объекте нанесения чернил в реальном времени (ЧРВ). Он также гарантирует, что если фокус был установлен, то не будет запаздывания или задержки.

Объектная модель

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

Первая часть представляет собой приложение 501 служб пера, которое поддерживает сбор электронных чернил. Примером является wisptis.exe, представленное компанией Microsoft Corporation и используемое в Windows XP Tablet Edition.

Во-вторых, служба 503 стило реального времени (показанная ассоциированной с процессом 1 502) представляет собой приложение, которое направляет данные стило от служб 501 пера на соответствующие окна для сбора. Служба 503 стило реального времени может манипулировать неограниченным количеством объектов или может ограничиваться для минимизирования по использованию. Например, если ограничивается, иллюстративным количеством объектов на тред может быть 16, 32, 64, 128 и т.п. Конечно, могут использоваться другие значения.

В-третьих, стило 504 и 505 реального времени показаны в процессе 1. Стило 504 и 505 реального времени могут принимать данные стило от службы 503 стило реального времени. Каждый объект стило реального времени может принимать данные стило для данной секции окна или области (основываясь на ассоциированном окне или области для этого объекта стило реального времени).

Чтобы показать, сколько процессов может быть реализовано одновременно, также показан процесс 2 506. Служба 507 стило реального времени также может принимать данные стило от служб 501 пера и направлять эту информацию на стило 508 и 509 реального времени.

Объекты 504, 505, 508 и 509 стило реального времени показаны более подробно на фиг.6. Компонент 601 служб пера направляет данные службе 602 стило реального времени в потоке А данных. Затем служба 602 стило реального времени направляет данные стило одному или нескольким компонентам 603 стило реального времени в потоке В данных. Альтернативно, как показано посредством службы 602 стило реального времени, показанной пунктирными линиями, эта служба может быть пропущена, и данные стило могут направляться прямо на компонент 603 стило реального времени.

Данные стило, принимаемые компонентом 603 стило реального времени, могут подаваться непосредственно на подключаемые компоненты 606-608. Альтернативно, принимаемые данные стило могут подаваться в его входную очередь 604 для упорядоченной обработки. Компонент 603 стило реального времени затем направляет данные стило одному или нескольким подключаемым компонентам. Эти компоненты 606-608 могут включать в себя динамический визуализатор 608 с хранилищем визуальных объектов, которое хранит визуализируемые в настоящий момент данные стило. Поток данных включает в себя потоки С и D.

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

Подключаемые компоненты 606-608 представляют собой объекты класса, которые могут отвечать на определенные вызовы через интерфейс для обработки данных стило. Один пример интерфейса, который может использоваться, включает в себя IStylusSyncPlugin. Объединение подключаемых компонентов 606-608 дает возможность разработчику полностью управлять, модифицировать и даже удалять данные из потока пакетов в подключаемых модулях. Модифицированный поток пакетов из потока Е данных затем запоминается в выходной очереди 605.

Выходной результат выходной очереди 605 направляется по потокам F и G данных на другую коллекцию подключаемых компонентов 610 и 611. Эти компоненты могут включать в себя распознаватель 610 жестов и объект 611 сбора чернил с хранилищем 612 чернил. Множество дополнительных подключаемых объектов могут ответвляться потоками F и G данных.

Решение на отделение подключаемых компонентов 606-608 из 610 и 611 может основываться на множестве критериев. Например, компоненты 606-608 могут быть синхронными подключаемыми модулями, и компоненты 610 и 611 могут быть асинхронными подключаемыми модулями. Альтернативно, подключаемые модули с более короткими временами манипулирования данными стило могут манипулироваться потоками C/D данных, и большие времена манипулирования данными стило могут адресоваться потоками F/G данных. Компоненты из одного треда C/D могут обмениваться с компонентами треда F/G.

Одним преимуществом разделения двух наборов подключаемых компонентов 606-608 и 610-611 является то, что подключаемые компоненты манипулируются различными тредами. В данном случае различие между синхронными подключаемыми модулями и асинхронными подключаемыми модулями заключается в треде, в котором они исполняются, и последовательности вызова (синхронные подключаемые модули могут вызываться тредом, в котором исполняется стило 603 реального времени, и асинхронные подключаемые модули вызываются обычно тредом пользовательского интерфейса/приложения, после того как поток пакетов будет обработан синхронными подключаемыми модулями и сохранен в выходной очереди 605).

В некоторых случаях может быть открытая передача от компонента 603 стило реального времени обратно службам 601 пера или службе 602 стило реального времени. В других случаях нет открытой передачи от компонента 603 стило реального времени обратно службам 601 пера или службе 602 стило реального времени. Предотвращение передачи может способствовать потоку данных от этих компонентов.

В некоторых ситуациях компонент 603 стило реального времени может уведомлять подключаемые модули при извлечении данных посредством посылки вызовов подключаемым модулям в предопределенной последовательности. Последовательность и типы подключаемых модулей, которые принимают эти уведомления, могут управляться разработчиком. Пакетные данные в событиях могут модифицироваться любым из этих подключаемых модулей 606-608 и 610-611.

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

Компонент 603 стило реального времени также может включать в себя очереди 604 и 605. Выходная очередь 605 может поддерживать все пакетные данные, которые обрабатывает компонент 603 стило реального времени. Если пакетные данные были возвращены от подключаемого модуля, пакетные данные добавляются в выходную очередь 605 из потока Е данных. Выходная очередь 605 затем может использоваться подключаемыми модулями (например, асинхронными и, в основном, включающими объект 611 сбора чернил). Это может происходить посредством извлечения данных из (потока F данных) и построения объекта чернил из данных, сохраняемых в выходной очереди 605, в потоке G данных.

Размер выходной очереди 605 может быть или может не быть постоянным. Если он постоянный, после того как очередь 605 будет заполнена, могут быть потеряны все принимаемые позже пакеты данных. Если он не постоянный, размер очереди 605 может увеличиваться для приема дополнительных пакетов данных. Одним преимуществом сохранения очереди постоянного размера является то, что она ограничивает задел данных до такого уровня, который может быть обработан в течение приемлемого периода времени. Например, если конечный пользователь взаимодействует с системой и она становится невосприимчивой, конечный пользователь обычно делает паузу до тех пор, пока система снова не станет восприимчивой, таким образом давая возможность очереди обрабатывать задел без потери данных. Также, если по некоторой причине был создан большой объем данных стило, очередь 605 может способствовать устранению некоторых данных посредством того, что она имеет постоянный размер.

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

Входная очередь 604 принимает информацию потока В данных (или если нет службы 602 стило реального времени, то тогда потока А данных). Входная очередь обеспечивает процесс для ввода данных в подключаемые модули 606-608. Альтернативно, данные стило могут передаваться непосредственно на подключаемые модули 606-608. Одним преимуществом наличия входной очереди 604 в качестве посредника между потоками В и С данных (в данном случае в качестве потока Z данных) является то, что она дает возможность вставлять созданные данные стило туда, где ничего нет.

Нижеследующее описывает высокоуровневый поток управления.

а. Стило 603 реального времени завершает обработку пакетных данных, проходящих через подключаемые модули 606-608.

b. Стило 603 реального времени хранит обработанные пакетные данные в выходной очереди 605.

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

d. Стило 603 реального времени просматривает, есть ли какие-либо ждущие обработки пакетные данные в службах 601 пера. Если есть, тогда пакетные данные из служб 601 пера забираются и обрабатываются на этапе а выше.

е. Данный процесс повторяется на этапе с.

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

а. Объект 603 стило реального времени проверяет сначала объекты данных подключаемых модулей в своей входной очереди 604 и затем из потока В данных пера планшета.

b. Объект 603 стило реального времени посылает С один объект данных подключаемого модуля объектам 606-608 в их коллекции синхронных подключаемых модулей. Каждый синхронный подключаемый модуль 606-608 может добавлять данные или во входную очередь 604, или в выходную очередь 605.

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

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

е. Когда выходная очередь 605 объекта стило реального времени содержит данные, объект 603 стило реального времени посылает один объект данных подключаемого модуля из его выходной очереди 605 объектам в его коллекции 610-611 асинхронных подключаемых модулей. Каждый асинхронный подключаемый модуль 610-611 может добавить данные или во входную очередь 604, или в выходную очередь 605. Но так как асинхронные подключаемые модули могут выполняться в треде пользовательского интерфейса (ПИФ), данные, добавляемые в очереди 604/605, не имеют установленной зависимости с остальными данными в потоке В данных пера планшета или с входными 604 и выходными очередями 605 объекта стило реального времени.

В-четвертых, система включает в себя асинхронный подключаемый модуль 611 (представленный в данном документе как объект сбора чернил). Объект сбора чернил в данном документе может представлять один или несколько объектов подключаемых модулей. Сбор и хранение чернил может быть одним из многочисленных действий, которые происходят в треде ПИФ или асинхронном треде. Если пакетные данные (или модифицированные пакетные данные) возвращаются от синхронных подключаемых модулей 606-608, они размещаются в выходной очереди 605 стило 603 реального времени. Стило 603 реального времени затем размещает данные в выходной очереди 605. Данные затем направляются следующему набору подключаемых модулей 610-611 (в коллекции или цепочке). Это может включать в себя направление данных объекту 611 сбора чернил, где они могут разрушаться/удаляться/повторно использоваться/освобождаться, что задается различными подключаемыми модулями в асинхронном треде.

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

На фиг.7 и 8 представлен альтернативный вариант структуры по фиг.6. На фиг.7 показаны службы 701 пера, предоставляющие данные стило для стило 702 реального времени. Входная очередь 703 (которая может использоваться или может не использоваться) предоставляет данные стило синхронным подключаемым модулям 801-805. В данном случае каждый подключаемый модуль представляет собой часть коллекции подключаемых модулей. Альтернативно, подключаемые модули могут быть частью цепочки подключаемых модулей. После последнего синхронного подключаемого модуля (синхронный подключаемый модуль N 805 стило реального времени) данные стило (или модифицированные данные стило) размещаются в выходной очереди 709, манипулируемой затем последующими асинхронными подключаемыми модулями 710 и 808 события стило реального времени.

Что касается данных по фиг.6 и 7, каждый набор данных, передаваемый через СРВ, может представлять собой единственный набор данных или комплект наборов данных, которые группируются вместе для эффективности, так как дигитайзер производит выборку с очень высокой скоростью. Эти наборы данных предусматривают уведомления о различных событиях или направляют новую информацию через СРВ. В некоторых ситуациях наборы данных могут удаляться. В других ситуациях, где набор данных представляет собой комплект наборов данных, может быть удален один набор данных в комплекте, в то же время оставляя другие наборы данных. Фактически комплект наборов данных модифицируется. Стило 702 реального времени затем может отправить закрытое сообщение в окно, к которому оно присоединено, и перейти к следующему набору данных во входной очереди (или, если ее нет, возвращает из функции, вызванной службами 701 пера в клиентском интерфейсе пера).

На фиг.8А и 8В показаны потоки данных для различных операций. На фиг.8А показано изменение цвета, принимаемое службами 701 пера. Стило 702 реального времени включает в себя коллекцию 809 синхронных подключаемых модулей и коллекцию 810 асинхронных подключаемых модулей. Коллекция синхронных подключаемых модулей включает в себя синхронный подключаемый модуль 1 801, динамический визуализатор 804 и синхронный подключаемый модуль 3 805. Выходной результат коллекции 809 синхронных подключаемых модулей посылается в выходную очередь 709. Коллекция 810 асинхронных подключаемых модулей принимает наборы данных из выходной очереди 709 и обрабатывает их в асинхронных подключаемых модулях 1-3 811, 812 и 813.

Для последующего описания фиг.8А и 8В используются пакеты данных. Однако понятно, что для передачи информации также могут использоваться другие наборы данных. Пакеты данных представляют собой лишь один пример типа наборов данных, который может использоваться. В данном случае стило 702 реального времени имеет два пакета А и В данных в выходной очереди 709. Пакет С данных в настоящий момент обрабатывается динамическим визуализатором 804, когда изменение СС цвета принимается службами 701 пера. Изменение СС цвета может немедленно передаваться и обрабатываться одним из асинхронных подключаемых модулей. Однако такое выполнение может создать сбивающую с толку ситуацию, когда пакеты А, В и С данных будут созданы перед изменением цвета. Следовательно, может быть желательным выполнить обработку изменения цвета только после окончательной обработки и окончательной визуализации пакетов А, В и С данных коллекцией 810 асинхронных подключаемых модулей.

Чтобы задержать обработку изменения СС цвета, один из синхронных подключаемых модулей в коллекции 809 подключаемых модулей может создать и протолкнуть объект СС₁ данных во входную очередь 703. Затем этот объект данных может быть обработан входной очередью в неавтономном режиме, причем результат изменения цвета представляется при помощи СС₂ в выходной очереди 709. Используя данный подход, инструкция на изменение цвета штрихов может быть надлежащим образом упорядочена с ранее принятыми пакетами данных.

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

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

На фиг.8В изображен компонент 702 стило реального времени, обрабатывающий пакеты данных и одновременно манипулирующий объектами распознавания жестов. Выходная очередь 709 включает в себя ряд объектов данных, включающих в себя событие (SD) опускания стило, пакеты (Р) данных и событие (SU) поднятия стило. Когда принимается событие SU поднятия стило от служб 701 пера в коллекции 809 синхронных подключаемых модулей, распознаватель жестов предпринимает попытку распознать жест из одного или нескольких предыдущих пакетов Р данных. Если пакет данных был распознан как жест, распознаватель 814 жестов генерирует объект GR распознавания жестов и помещает его во входную очередь 703. Распознавание жеста объекта GR затем посылается при помощи синхронных подключаемых модулей и направляется в выходную очередь 709. Из выходной очереди 709 объект GR распознавания жеста передается при помощи асинхронных подключаемых модулей, затем разрушается/удаляется/повторно используется/освобождается. Преимущество того, что объект распознавания жеста создается и передается обратно при помощи коллекции 809 подключаемых модулей ввода, заключается в том, что обработка позволяет модифицировать и/или удалять принимаемый объект распознавания жестов до направления в выходную очередь 709. Далее посредством манипулирования объектом GR распознавания жестов при помощи коллекции 809 синхронных подключаемых модулей и коллекции 810 асинхронных подключаемых модулей могут быть удалены пакеты данных между событиями опускания стило и поднятия стило, так как они замещаются существованием объекта GR жеста. Альтернативно, события могут игнорироваться в отношении данных, которым жест соответствует и которые все же могут иметь отношение для других подключаемых модулей по направлению потока данных. Вообще говоря, система управляет, какие подключаемые модули присутствуют, когда присутствует распознаватель жестов, так что характер изменения согласуется с требуемым результатом разработчиков, а именно, что данные, которые игнорируются, фактически удаляются из структуры данных, после того как они там были размещены.

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

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

а. игнорирование уведомления от первого такого пакета,

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

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

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

Специальные данные стило могут быть добавлены к объекту стило реального времени посредством вызова метода AddCustomStylusDataToQueue. Если вызов метода AddCustomStylusDataToQueue выполняется из синхронного подключаемого модуля в ответ на вызов одного из его методов IStylusSyncPlugin, тогда специальные данные стило добавляются к потоку данных пера планшета детерминированным образом; иначе они добавляются недетерминированным образом. Метод AddCustomStylusDataToQueue создает исключительную ситуацию, если блокируется объект RealTimeStylus.

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

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

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

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

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

Специальные данные стило добавляются в очередь в качестве объекта специальных данных стило, и подключаемые модули принимают эти данные при помощи их метода IStylusSyncPlugin.CustomStylusDataAdded или IStylusAsyncPlugin.CustomStylusDataAdded.

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

Объект стило реального времени вызывает метод IStylusSyncPlugin.CustomStylusDataAdded в треде, с которого он принимает вызов своего метода AddCustomStylusDataToQueue.

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

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

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

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

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

Объект динамического визуализатора реализует интерфейс IStylusSyncPlugin. Динамический визуализатор может дополнительно реализовать асинхронный интерфейс. Объект динамического визуализатора визуализирует чернила в реальном времени, когда они рисуются. По умолчанию, когда вызывается метод обновления, объект динамического визуализатора перерисовывает штрих, сбор которого происходит в данный момент, вместе с любыми другими ранее собранными штрихами (которые соответствуют CachedData DynamicRenderer. Возможны другие перегрузки характера изменения обновления, которые включают в себя параметры для ограничения характера изменения рисования, например, с областью отсечения, так что чернила не визуализируются вне данной формы.

Это изображено на различных фигурах (что объект динамического визуализатора может временно кэшировать данные чернил). Когда объект динамического визуализатора принимает вызов своего метода IStylusSyncPlugin.StylusUp, он кэширует данные штриха и добавляет специальные данные стило во входную очередь в ответ на объект StylusUpData для штриха. Свойство CustomDataId объекта CustomStylusData устанавливается на значение DynamicRendererCachedDataGuid, и свойство Data объекта CustomStylusData содержит объект DynamicRendererCachedData. Затем можно очистить кэш динамического визуализатора от ассоциированных данных, если чернила были визуализированы по направлению потока данных. Альтернативно, обновление чернил (перерисовка текущих штрихов и данных, хранимых в CachedData) не всегда может очищать кэш динамического визуализатора от штрихов чернил, так как эти штрихи чернил могли быть еще не переданы и не сохранены объектом сбора чернил.

На фиг.9 и 10 показаны процессы для установления аспектов настоящей системы. На фиг.9 на этапе 901 создается экземпляр компонента стило реального времени. На этапе 902 создается экземпляр синхронных и асинхронных подключаемых модулей. Он может включать в себя или может не включать в себя создание экземпляра динамического визуализатора и/или распознавателя 903 жестов. На этапе 904 подключаемые модули добавляются в коллекции подключаемых модулей. На этапе 905 разрешается стило реального времени. На этапе 906 данные пера принимаются при помощи стило реального времени.

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

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

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

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

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

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

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

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

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

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

На этапе 1006 пакет проходит через асинхронные подключаемые модули в коллекции.

Динамическая визуализация и влажные чернила

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

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

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

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

Ссылаясь на фиг.6, ввод дигитайзера поступает от служб 601 пера и подается на стило 603 реального времени. Стило реального времени пропускает ввод дигитайзера через многочисленные объекты 606-608 синхронных подключаемых модулей и запоминает результат в выходной очереди 605. Объекты 606-608 могут соединяться при помощи интерфейса, который описывает связь между объектами 606-608, например, IStylusSyncPlugin. Коллекция асинхронных подключаемых модулей объектов 610-611 затем принимает выходной результат от выходной очереди 605 и начинает его обрабатывать. Например, объект 611 сбора чернил может извлекать ввод дигитайзера из выходной очереди и запоминать его как чернила. Динамическая визуализация ввода дигитайзера происходит тогда, когда компонент 603 стило реального времени пропускает ввод дигитайзера (модифицированный или нет) через динамический визуализатор 608. Статическая визуализация ввода дигитайзера (модифицированного или нет) происходит тогда, когда ввод дигитайзера запоминается в хранилище чернил объекта 611 сбора чернил.

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

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

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

На фиг.11 показано, как объект сбора чернил предупреждает динамический визуализатор об освобождении его кэшированных данных. Динамический визуализатор 1201 включает в себя хранилище 1202 визуальных объектов. Объект сбора чернил включает в себя хранилище 1204 чернил. Если динамический визуализатор 1201 сохранил данные стило в хранилище 1202 визуальных объектов, он выводит объект во входную очередь 1205. Стило реального времени (например, 702) исследует входную очередь в отношении следующих данных для обработки до просмотра служб 701 пера. Для целей данного документа объект, введенный во входную очередь, упоминается как DynamicRendererCachedData. Объект затем принимается стило 702 реального времени (с дополнительной обработкой или без нее), и он выводит его в выходную очередь 1206. Тем временем, объект 1203 сбора чернил обрабатывает принимаемые пакеты ввода стило в порядке их появления в выходной очереди 1206. Когда объект 1203 сбора чернил встречает объект от динамического визуализатора 1201 (в данном случае объект DynamicRendererCachedData), он выполняет следующее:

а. создает сопоставимый соответствующим образом штрих, который совпадает со штрихом, визуализируемым динамическим визуализатором;

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

с. посылает уведомление об освобождении динамическому визуализатору 1201. Это уведомление может включать в себя исполнение метода на динамическом визуализаторе и передачу параметра.

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

Атрибуты рисования могут быть установлены в системе в соответствии с требованиями разработчика, или среди других подходов могут предусматриваться в объекте, передаваемом объекту 1203 сбора чернил. Уведомлением об освобождении может быть вызов интерфейса, предусматриваемого динамическим визуализатором 1201. В данном случае уведомлением может быть ReleaseCachedData.

На фиг.12 показан альтернативный подход к манипулированию влажными чернилами. Фиг.12 включает в себя ввод 701 служб пера, посылающий данные стило на стило 702 реального времени. Входная очередь 703 может манипулировать и ставить в очередь вводы, причем результаты приемников событий стило реального времени помещаются в выходную очередь 709. Фиг.12 включает в себя дополнительную очередь 1101. Эта очередь манипулирует результатами от динамического визуализатора 1102, который был отделен от других приемников А 1103 и В 1104 событий стило реального времени. Здесь данный подход обращает внимание на вопрос, который может иметь место, при котором приемники А 1103 и/или В 1104 событий стило реального времени замедляют появление чернил, вытекающих из стило. Система по фиг.12 манипулирует динамической визуализацией данных стило, до того как она будет манипулировать другими приемниками А 1103 и В 1104 событий. Даже если приемники А 1103 и В 1104 событий могут все же вызывать задержки в обработке данных стило на их пути к объекту 1105 сбора чернил, приемник событий динамической визуализации 1102 может продолжать обрабатывать данные стило, по мере того как они принимаются. В данном случае, как только данные стило визуализируются динамическим визуализатором 1102, выходной результат посылается в дополнительную очередь 1101, где к нему затем обращаются приемники А 1103 и В 1104 событий реального времени. Отметьте, что процесс того, как обращаются к приемникам А 1103 и В 1104 событий реального времени (один вызывает другой, или оба вызываются посредством дополнительной очереди 1101), может выполняться при любом подходе.

На фиг.13 показан еще другой аспект того, как обеспечить то, что влажные чернила вытекают из стило. В данном случае в отдельном треде существует вторичный объект стило реального времени. Службы 701 пера выводят данные стило компоненту 1301 стило реального времени. Входная очередь 1302 предоставляет данные стило динамическому визуализатору 1303. Другие синхронные подключаемые модули могут быть ассоциированы или могут не быть ассоциированы с компонентом 1301 стило реального времени. Необязательные синхронные подключаемые модули включают в себя распознаватель 1304 жестов и другие синхронные подключаемые модули 1305. Выходной результат от этих синхронных подключаемых модулей направляется в выходную очередь 1306. В данном случае компонент 1307 стило реального времени соединяется с выходной очередью 1306 от компонента 1301 стило реального времени. Компонент 1307 стило реального времени и ассоциированные с ним синхронные подключаемые модули 1309-1313 и асинхронные подключаемые модули 1312-1313 служат в качестве асинхронного подключаемого модуля с позиции компонента 1301 стило реального времени. Пакеты данных (однако модифицированные синхронными подключаемыми модулями компонента 1301 стило реального времени) направляются коллекции синхронных подключаемых модулей для компонента 1307 стило реального времени. Например, коллекция синхронных подключаемых модулей для компонента 1307 стило реального времени включает в себя синхронный подключаемый модуль А 1309, компонент В 1310 синхронного подключаемого модуля и (если не использовался ранее) распознаватель 1313 жестов. Понятно, что распознаватель 1313 жестов представляет собой подключаемый модуль типа, который может ассоциироваться с синхронным тредом или асинхронным тредом для любого компонента стило реального времени. Ассоциация распознавателя 1313 жестов с коллекцией синхронных подключаемых модулей для компонента 1307 стило реального времени представлена исключительно для иллюстративных целей.

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

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

Распознавание жестов

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

Распознаватель 610 жестов может использовать алгоритм. В данном случае распознаватель жестов может использовать алгоритм перестановки для распознавания многоштриховых жестов. Например, когда было установлено свойство, относящееся к максимальному количеству штрихов, распознаватель жестов просматривает в обратном направлении на это количество штрихов. Например, если свойство установлено на 2, распознаватель жестов просматривает в обратном направлении самые последние 2 штриха, пытаясь распознать их как жест. Это может приводить к многочисленным вызовам распознавания. Однако данный подход устраняет постоянную задержку из-за необходимости ожидания запуска обработки распознавателем жестов после последнего штриха.

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

Если объект 611 сбора чернил принимает объект жеста (в данном случае GestureRecognitionData), он удаляет штрихи для жеста из хранилища 612 чернил и выполняет соответствующие действия под действием жеста.

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

Распознаватель жестов может быть реализован как объект с различными интерфейсами. Например, объект распознавателя жестов может реализовать интерфейсы IStylusSyncPlugin и IStylusAsyncPlugin.

Когда объект распознавателя жестов распознает жест, он добавляет специальные данные стило во входную очередь под действием объекта StylusUpData для штриха. Свойство CustomDataId объекта CustomStylusData устанавливается на значение GestureRecognitionDataGuid, и свойство Data объекта CustomStylusData содержит объект GestureRecognitionData.

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

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

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

а. Посредством передачи информации о штрихе существующему объекту Recognizer и использования метода AddCustomStylusDataToQueue для добавления результатов потоку данных пера.

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

с. Посредством заключения в оболочку стандартного подключаемого модуля распознавателя жестов специальным подключаемым модулем, который вызывает стандартный подключаемый модуль по способу гирляндной цепочки. Таким образом разработчик может реализовать распознавание жестов в воздухе посредством «преобразования» in-air-packet в Packets, Cursor-In-Range в StylusDown и CursorOutOfRange в StylusUp.

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

Описание SystemGesture

Синхронные и асинхронные процессы

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

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

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

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

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

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

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

Каскадирование

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

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

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

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

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

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

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

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

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

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

Модификация коллекции динамически подключаемых модулей

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

Чтобы обеспечить расчет по времени, где подключаемые модули могут инициализировать и очищать, «искусственные» (означающие, не возникающие от действительных вызовов клиентского кода для разрешения и запрещения) вызовы RealTimeStylusEnabled & RealTimeStylusDisabled могут быть выполнены для подключаемых модулей, которые динамически вставляются или удаляются из коллекций подключаемых модулей.

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

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

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

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

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

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

Распространение ошибок

Период проектирования

Хотя в среде разработки (например, Visual Studio.NET компании Microsoft Corporation) разработчики могут приостанавливать при любом Exception, который устанавливается независимо от того, захвачен он или нет при помощи блоков try/catch. Поэтому сообщение об ошибках простое для цели обнаружения недействительных конфигураций инфраструктуры RealTimeStylus.

Время выполнения

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

Стандартной обработкой ошибок .NET является запуск событий из подключаемых модулей, когда происходят исключительные ситуации, и ожидание этого события кодом обработки ошибок разработчика в треде ПИФ. Впрочем это не работает для Real Time Stylus, так как, когда подключаемый модуль запускает событие, существует вероятность, что данные, которые вызвали исключительную ситуацию, могли не достичь треда ПИФ из-за постановки в очередь. Это ставит под вопрос проведение красивой обработки ошибок без доступности контекста (а именно неправильных данных, а также предыдущих и последующих данных), в котором произошла исключительная ситуация для кода обработки ошибок. Данный подход является хорошим только для упрощенческой обработки ошибок, такой как установление диалога по исправлению ошибок и завершение приложения.

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

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

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

Как показано на фиг.15, стило 603 реального времени захватывает все исключительные ситуации, поступающие от подключаемых модулей 606-608, и создает объект ErrorData. Следующее показывает процесс идентификации ошибок:

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

i. Альтернативным подходом является немедленная передача объекта ErrorData через оставшиеся подключаемые модули в коллекции до фактических данных, которые вызвали исключительную ситуацию.

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

с. ErrorData, в конце концов, ставится в выходную очередь, если исключительная ситуация произошла в синхронных подключаемых модулях, или доставляется асинхронным подключаемым модулям.

d. После того как ErrorData будет передан через коллекцию, данные, которые вызвали исключительную ситуацию, передаются через оставшиеся подключаемые модули в коллекции.

Объект ErrorData может быть передан через коллекцию подключаемых модулей при помощи назначенных методов (например, метода IStylusSyncPlugin.Error или метода IStylusAsyncPlugin.Error).

Более конкретно, когда подключаемый модуль создает исключительную ситуацию, прерывается нормальный поток данных. Объект стило реального времени генерирует объект ErrorData и вызывает метод IStylusSyncPlugin.Error или IStylusAsyncPlugin.Error подключаемого модуля, который создает исключительную ситуацию, и метод IStylusSyncPlugin.Error или IStylusAsyncPlugin.Error оставшихся подключаемых модулей в этой коллекции. Если подключаемый модуль, который создает исключительную ситуацию, представляет собой синхронный подключаемый модуль, объект ErrorData добавляется в выходную очередь. Затем объект стило реального времени возобновляет нормальную обработку исходных данных.

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

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

Объект стило реального времени вызывает метод IStylusSyncPlugin.Error в треде, из которого создается исключительная ситуация.

Управляемые/неуправляемые иллюстрации

На фиг.16 показаны различные подходы для внедрения аспектов настоящего изобретения. Система может включать в себя объекты МКО, заключенные в оболочку посредством коллекции управляемых объектов языка C#. Альтернативно, может использоваться любой объектно-ориентированный язык, включая Java, C++ и т.п.

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

Службы 1601 пера посылают данные стило компоненту 1602 стило реального времени, причем его входная очередь 1603 и выходная очередь 1604 находятся в области неуправляемого кода. Данные стило передаются компоненту 1605 стило реального времени в области управляемого кода.

Динамический визуализатор представляет собой первый синхронный подключаемый модуль, присоединенный к компоненту стило реального времени. В неуправляемом пространстве динамический визуализатор 1608 с его кэшем 1616 данных присоединен к компоненту 1602 стило реального времени. Аналогично в управляемом пространстве динамический визуализатор 1615 с его кэшем 1617 данных представляет собой часть коллекции синхронных подключаемых модулей для компонента 1605 стило реального времени. Следующим синхронным подключаемым модулем в коллекции синхронных подключаемых модулей является синхронный подключаемый модуль 1607. Синхронный подключаемый модуль 1607 следует за динамическим визуализатором в коллекции синхронных подключаемых модулей для компонента 1605 RealTimeStylus. Так как синхронный подключаемый модуль Y 1607 существует только в управляемом пространстве, оболочка 1618 синхронного подключаемого модуля дает возможность неуправляемому компоненту 1602 RealTimeStylus обращаться к синхронному подключаемому модулю 1607 через границу управляемого/неуправляемого пространства.

На фиг.16 также показана коллекция асинхронных подключаемых модулей. Асинхронные подключаемые модули включают в себя синхронный подключаемый модуль 1612 и распознаватель 1609 жестов. Асинхронный подключаемый модуль 1612 представляет собой первый асинхронный подключаемый модуль в коллекции асинхронных подключаемых модулей, присоединенной к компоненту 1605 RealTimeStylus в управляемом пространстве. Так как асинхронный подключаемый модуль 1612 находится в управляемом пространстве, оболочка 1619 асинхронного подключаемого модуля может использоваться для того, чтобы дать возможность обращения к нему из неуправляемого компонента 1602 RealTimeStylus. Распознаватель жестов существует как в управляемом пространстве, так и в неуправляемом пространстве. Управляемый распознаватель 1609 жестов со своим кэшем 1610 данных представляет собой следующий подключаемый модуль, к которому происходит обращение после асинхронного подключаемого модуля 1612. Распознаватель 1609 жестов может обмениваться информацией с неуправляемой версией распознавателя (1613 с его кэшем 1614 данных) жестов.

Может потребоваться преобразование или «маршалинг» данных, переходящих между управляемой и неуправляемой сторонами фиг.16, между структурами, используемыми в неуправляемом пространстве, и структурами, используемыми в управляемом пространстве. .NET Framework компании Microsoft Corporation обеспечивает уровень возможности взаимодействия, который выполняет большую часть этого маршалинга автоматически. Эта дополнительная обработка данных следует из подразумеваемого ухудшения характеристик, поэтому конструкция, показанная на фиг.16, настраивается на минимизацию количества пересечений уровня возможности взаимодействия.

Зависимость между управляемой оболочкой для СРВ 1605 и неуправляемым СРВ 1602 заключается в том, что для собственного (неуправляемого СРВ 1602) управляемый СРВ 1605 выглядит как другой приемник событий СРВ. Когда создается экземпляр динамического визуализатора 1615 в его конструкторе, СРВ 1605 обращается к соответствующему неуправляемому динамическому визуализатору 1608 и привязывает его после себя к коллекции синхронных подключаемых модулей.

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

На фиг.16 также показаны объекты 1615 и 1608 управляемого и неуправляемого динамического визуализатора. Объект управляемого динамического визуализатора может представлять собой тонкую оболочку над свойствами неуправляемого динамического визуализатора 1608. Управляемый динамический визуализатор 1615 является необязательным. Если в данном случае не создается экземпляр динамического визуализатора 1615, он может быть создан как один из других синхронных подключаемых модулей.

Нижеследующее представляет собой процесс создания системы по фиг.16:

а. Во-первых, разработчик создает экземпляр управляемого асинхронного подключаемого модуля 1612 и управляемого динамического визуализатора 1615. Внутренне динамический визуализатор 1615 создает экземпляр неуправляемого динамического визуализатора 1608 для передачи установок свойств.

b. Во-вторых, разработчик устанавливает свойства динамического визуализатора 1615 (атрибуты рисования и т.д.)

с. В-третьих, разработчик создает экземпляр стило 1602 реального времени, переводя динамический визуализатор 1615 в конструкторе стило реального времени. Внутренне могут произойти следующие вещи:

i. Управляемое стило 1605 реального времени запрашивает (при помощи открытого изолированного аксессора) адрес неуправляемого динамического визуализатора 1608.

ii. Управляемое стило реального времени создает экземпляр собственного стило 1602 реального времени, который привязывает себя к службам 1601 пера.

iii. Управляемое стило 1605 реального времени привязывает себя к собственному стило 1602 реального времени в качестве приемника событий стило реального времени.

iv. Управляемое стило 1605 реального времени привязывает собственный динамический визуализатор 1608 к его синхронному выходному результату.

v. Управляемое стило 1605 реального времени привязывает себя к треду синхронного подключаемого модуля собственного стило 1602 реального времени.

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

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

f. В-шестых, разработчик ассоциирует объект 1612 управляемого асинхронного подключаемого модуля со свойством InkCollectionObject управляемого стило 1605 реального времени (таким образом привязывая объект 1612 асинхронного подключаемого модуля к коллекции асинхронных подключаемых модулей).

g. В-седьмых, разработчик устанавливает RTS.Enabled в «true». Это также может вызвать управляемым стило 1605 реального времени установку IRealTimeStylus->Enabled в «true» на собственном стило 1602 реального времени.

h. В-восьмых, события начинают движение в потоке через стило 1602 реального времени.

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

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

Нижеследующее описывает процесс использования системы по фиг.16.

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

b. Собственное СРВ 1602 выполняет следующее, когда новые данные появляются во входной очереди 1603 (или когда соответствующий метод вызывается в интерфейсе, который он объявляет службам 1601 пера):

i. преобразует пакеты из пространства дигитайзера в метрический режим отображения с высоким разрешением (himetric) («пространство чернил»);

ii. внедряет обратное преобразование (метрический режим отображения с высоким разрешением > дигитайзер) в пакетные данные и

iii. передает преобразованные пакетные данные первому синхронному подключаемому модулю коллекции подключаемых модулей посредством вызова соответствующей функции для данных в интерфейсе коллекции синхронных подключаемых модулей (управляемое СРВ в данном случае).

с. Управляемое СРВ 1605 выполняет следующее:

i. создает соответствующие управляемые структуры данных для хранения данных управляемым и дружелюбным образом;

ii. вызывает соответствующую функцию собранных управляемых синхронных подключаемых модулей;

iii. обеспечивает то, что каждый подключаемый модуль обрабатывает данные и возвращает обратно компоненту 1605 RealTimeStylus, так что может быть вызван следующий подключаемый модуль; и

iv. и т.д. до тех пор, пока он не вызовет соответствующую функцию распознавателя 1609 жестов (если используется распознаватель 1609 жестов).

d. Динамический визуализатор 1615 может вызываться посредством RealTimeStylus 1605. Когда динамический визуализатор 1615 завершает визуализацию новых пакетов, он возвращает, что неуправляемое СРВ 1602 обнаруживает, были ли модифицированы пакетные данные, и помещает соответствующие данные в очередь. Если были любые «не-немедленные» элементы пользовательских данных, он добавляет их теперь.

е. Собственное СРВ 1602 затем отправляет закрытое сообщение присоединенному окну; и

f. собственное СРВ 1602 затем просматривает во входной очереди 1603, были ли добавлены какие-либо данные реального времени, и, если это так, вызывает коллекцию синхронных подключаемых модулей, снова передавая эти данные. Если данные не были добавлены, собственное СРВ 1602 возвращает, давая возможность службам 1601 пера продолжить обработку и снова вызвать СРВ 1602 с новыми данными дигитайзера.

g. Закрытое сообщение просматривается процедурой подкласса собственного СРВ 1602, которое извлекает данные из очереди 1603 и вызывает соответствующую функцию присоединенного интерфейса синхронного подключаемого модуля.

h. В данном случае управляемое СРВ 1605 подсоединило себя и вызывается. Управляемое СРВ 1605 затем вызывает соответствующую функцию асинхронного подключаемого модуля 1612. Это может быть передано через оболочку 1619 асинхронного подключаемого модуля.

i. Управляемый асинхронный подключаемый модуль 1612 затем асинхронно обрабатывает данные, визуализируя или накапливая, что необходимо.

j. Может быть вызван распознаватель 1609 жестов как часть коллекции асинхронных подключаемых модулей компонента RealTimeStylus. Распознаватель 1609 жестов внутренне накапливает пакеты, пока не встретится CursorUp, в этот момент накопленные пакеты передаются через границу возможности взаимодействия в собственный распознаватель 1613 жестов для распознавания.

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

ii. Распознаватель 1609 жестов затем использует метод AddUserDataToQueue управляемого СРВ 1605 (причем «немедленный» установлено на «false») для помещения результатов распознавания жестов в очередь 1604 для асинхронного потребления (это вызывает немедленное пересечение новыми данными жестов границы возможного взаимодействия и помещение в другую очередь, пока собственная коллекция подключаемых модулей не будет завершена).

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

iv. Текущие данные затем возвращаются распознавателем 1609 жестов компоненту 1605 RealTimeStylus для любых дополнительных подключаемых модулей в коллекции подключаемых модулей.

Наборы и потоки данных

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

Source IRealTimePen	Этот обратный указатель предоставляет реализации приемника событий обратной ссылки на исходный RealTimeStylus. Этот указатель предоставляет две вещи: (а) обращение к контекстной информации об экземпляре стило (например, DynamicRenderer 1615 должен быть способен выполнять преобразование единиц между координатами дигитайзера и пикселями) и (b) совместное использование многочисленными цепочками событий СРВ.
TabletContextID	Дает возможность потребителю данных реального времени эффективно накапливать данные и использовать идентификатор (ИД) планшета в качестве индексатора в коллекции данных.
PacketDescription	Описывает размещение данных в вызове пакета. Различные дигитайзеры поддерживают различные количества информации, включая (например) x, y, давление, угол. PacketDescription указывает получателю пакета, как эти данные расположены в плоской матрице целых чисел, которые в итоге поступают.
CursorID	Дает возможность потребителю данных реального времени эффективно накапливать данные и использовать ИД курсора в качестве индексатора для коллекции данных.
StylusInfo	Простая структура, которая объединяет подходящую информацию, включающую в себя: TableContextID; CursorID; Inverted State (это три состояния, указывающие уместность и соответствует ли курсор концу с «ластиком» или «пишущему» концу пера); Button State (нажаты ли каждая из 32 кнопок); и Другая уместная информация, которая необходима.
PropertyCountPerPacket	Параметр компромисса, который дает возможность разработчику логически выводить размещение пакетных данных без вызова ИПП. (гарантируется, что Х, Y являются первыми и в этом порядке, и счет дает возможность разработчику, заинтересованному только в данных x, y, пройти по списку, пропуская каждый n-й элемент).
CountOfPackets	Количество пакетов «связанных вместе» для эффективности (Службы пера и/или драйвер устройства дигитайзера определяет, когда и сколько пакетов связываются таким образом).
PacketData	Это копия только для чтения пакетных данных.
CountOfPacketRef	Количество пакетов в модифицированном наборе packetdata, который могут назначить разработчики подключаемых модулей.
PacketDataRef	Это ссылка на пакетные данные, которые дают разработчикам объектов подключаемых модулей возможность модифицировать пакетные данные, чтобы выполнить сценарии, которые включают в себя манипулирование данными реального времени.

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

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

Синхронизация данных

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

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

На фиг.17А показан переключатель режима, который происходит, когда система обрабатывает информацию. Система показывает завершение первой обработки («выполнено») в позиции 1701. В момент 1702 времени новые данные стило принимаются и начинают обрабатываться подключаемым модулем 1 в момент 1702 времени и подключаемым модулем 2 в момент 1704 времени, и обработка завершается в момент 1705 времени. Переключение режима происходит в момент 1703 времени. Например, если пользователь приложения изменяет «режим редактирования» с «нанесения чернил» на «стереть» и приложение занято, существует приемлемая вероятность того, что пакетные данные, выходящие потоком из очереди, все еще относятся к «нанесению чернил» в течение некоторого времени, после того как изменился режим пользователя.

Однако вместо добавления события переключения режима в очередь 1706 в настоящий момент времени оно задерживается до тех пор, пока текущая обработка не будет завершена в момент 1705 времени для данных стило. Это может происходить двумя путями. Во-первых, событие срабатывания переключения режима может задерживаться до тех пор, пока не будут завершены данные стило, начинающиеся в подключаемых модулях в момент 1702 времени. Во-вторых, система может вводить событие переключения режима в очередь 1706, оставляя достаточное пространство для размещения результата от подключаемого модуля 2 в момент 1705 времени перед ним в очереди 1706. Поэтому в данном случае ОСЧ может вставить «маркер» в выходную очередь в момент, в который пользователь выполнил изменение режима. После истечения периода времени этот маркер будет передан обратно в ОСЧ (при помощи метода CustomDataAdded интерфейса коллекции подключаемых модулей стило реального времени), причем в этой точке ОСЧ может начать интерпретацию поступающих пакетных данных в качестве запросов «ластика».

На фиг.17В показана обобщенная версия фиг.17А. Завершение процесса для первого треда показано событием 1707. Оно размещается в очереди 1712. Затем в момент 1708 времени начинается другой процесс в первом треде. В момент 1709 времени происходит событие во втором треде. Так как процесс в первом треде начался в момент 1708 времени, ожидается, что процесс будет адресован до события в момент 1709 времени. Однако, так как процесс в первом треде продолжается в момент 1710 времени, затем завершается в момент 1711 времени, расчет по времени вставления события в момент 1709 времени относительно времени начала процесса 1708 был бы нежелательным в том, что событие в момент 1709 времени было бы размещено в очереди перед процессом, завершаемым в момент 1711 времени. В данном случае на фиг.17В показано, что событие в момент 1711 времени вставляется на некотором расстоянии по течению потока данных в очередь 1712 от события, генерируемого из точки 1707 выполнения процесса, посредством пропуска по меньшей мере одного места в очереди 1712. Сохранение места, доступного в очереди 1712, дает возможность правильно размещать завершение процесса 1708, 1710, 1711 в очереди 1712 в позиции перед событием в 1709, чтобы сделать возможным, что считывание пакетов/событий в очереди 1712 происходило в ожидаемом порядке. В данном случае порядок может быть резюмирован как пакеты/события, происходящие в порядке, в каком начались их процессы или произошли события. Это упорядочение продолжается для следующего процесса, показанного точками 1713 (начало процесса), 1714 (продолжение процесса) и 1715 (процесс выполнен).

На фиг.18 и 19 показаны различные системы для манипулирования данными пера согласно аспектам настоящего изобретения.

Как показано на фиг.18, устройство 1801 пера посылает данные службам 1803 пера. Мышь 1802 также может генерировать информацию и посылать ее user32 (также известному как user32.dll) 1804. Некоторые данные пера (щелчок кнопками, например) могут представлять события мыши и перенаправляются на user32 1804 для обработки как события мыши. Аналогично, некоторые события мыши могут представлять чернила и перенаправляются на 1814 для обработки в качестве ввода пера. События мыши затем передаются конвейеру 1805 сообщений окон, затем описателю 1806 окна (ОПОК), устройству 1812 мыши ОПОК, входной очереди 1810 и затем менеджеру 1811 ввода. Ввод пера (например, когда перо перемещается в диапазон потенциальной службы нанесения чернил), или событие стило посылается менеджеру 1807/1808 ввода пера (службы неуправляемого и управляемого стило реального времени). Менеджер 1807/1808 ввода пера манипулирует всеми передачами между службами 1803 пера и приложением. Это манипулирование может выполняться в треде с нормальным приоритетом или в треде состояния с высоким приоритетом. Службы 1803 пера могут генерировать различные события. События пера могут посылаться менеджеру 1807/1808 ввода пера в обход стандартной системы 1804-1806 и 1812 обмена сообщениями.

Службы 1803 пера могут генерировать следующие события: стило в диапазоне (где стило перешло в диапазон дигитайзера), стило вне диапазона (где стило больше не может быть обнаружено дигитайзером), пакеты стило (необработанные данные точки от дигитайзера – перо может быть или может не быть в контакте с дигитайзером), стило в точках воздуха, планшет добавлен/удален и события системных жестов (например, «нажми и держи» и события висения).

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

а. Проверку, является ли событие событием «пакета» опускания. Если нет, остановить обработку и возвратить null.

b. Проверку, было ли событие на элементе нанесения чернил, основываясь на его кэшированной информации о размещении. Если нет, остановить обработку и возвратить null.

с. Так как этот пакет для события «опускания» внутри области нанесения чернил, тогда пошагово рисовать штрих.

d. Наконец вернуть менеджеру 1807/1808 ввода пера элемент, на котором был нарисован штрих.

Возвращаемое значение из события необработанного предварительного просмотра используется менеджером 1807/1808 ввода пера для «определения цели» события. Если возвращается цель, не равная null, тогда событие может быть размещено во входной очереди с этой конкретной целью. Это гарантирует то, что чернила, которые были нарисованы на элементе, фактически доставляются этому элементу, а не некоторому другому элементу как результат других событий во входной очереди.

Теперь событие стило готово стать событием ввода. Однако во многих случаях каждое событие стило также имеет соответствующее сообщение мыши, протекающее через систему обмена сообщениями. Перед тем как менеджер 1807/1808 ввода пера сможет преобразовать событие стило в событие ввода, он должен сначала согласовать событие с соответствующим сообщением мыши. Если необходимо, менеджер 1807/1808 ввода пера может ожидать поступление сообщения мыши.

Если менеджер 1807/1808 ввода пера имеет как сообщение мыши, так и событие стило, он объединяет два в соответствующий отчет ввода и размещает отчет во входной очереди 1810.

На фиг.20 показана очередь согласно аспектам настоящего изобретения. Фиг.20 включает в себя очередь 2001. Для простоты очередь показана в виде круга. Также могут использоваться альтернативные формы очереди, включающие в себя линейную очередь и другие варианты, как известно в технике. Очередь 2001 включает в себя указатель 2002 начала и указатель 2008 конца. Очередь 2001 также включает в себя ряд позиций, имеющих информацию (2003, 2004 и 2009). Позиции 2005 и 2007 пустые. Позиция 2006 была заблокирована. Позиция 2006 может блокироваться в виде символа-заполнителя для синхронизации событий и данных от различных источников (пример которых показан на фиг.17А и 17В). Также позиция 2006 может блокироваться, когда данные, содержащиеся в ней, передаются через коллекцию или цепочку подключаемых модулей. Позиции 2010 и 2011 также пустые. Количество пустых пространств может увеличиваться или уменьшаться по необходимости. Например, могут быть добавлены дополнительные пространства для хранения дополнительных данных, если очередь полная. Альтернативно, размер очереди может быть постоянным, так что отбрасываются любые данные, которые свыше того, что может храниться в очереди. Это может обеспечивать полезное преимущество для пользователя в том, что это обеспечивает указание пользователю, что система в большой степени участвует в других процессах, и было бы полезным замедлить создание новых данных для очереди. Отбрасывание информации также может демонстрировать пользователю, что система заблокирована, и нежелателен ввод дополнительных данных до тех пор, пока система снова не продолжит обработку.

Интерфейсы прикладного программирования

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

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

Чтобы дать возможность подключаемым модулям взаимодействовать с потоком данных пера, объект стило реального времени может поддерживать две коллекции подключаемых модулей. Коллекции могут быть заданы в свойстве объекта стило реального времени (например, SyncPluginCollection для синхронных подключаемых модулей и AsyncPluginCollection для асинхронных подключаемых модулей). Можно добавить подключаемый модуль к обеим коллекциям посредством вызова метода добавления (например, StylusSyncPluginCollection.Add для добавления подключаемого модуля к синхронной коллекции или StyluAsyncPluginCollection.Add для добавления подключаемого модуля в асинхронную коллекцию) соответствующего свойства.

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

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

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

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

а. Создать форму, которая реализовывает интерфейс IStylusAsyncPlugin.

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

с. Установить форму, которая заинтересована в (и поэтому принять) уведомлениях, относящихся к стило, контактирующему поверхность (событие StylusDown), пакетах данных и уведомлениях о поднятии стило (например, событие StylusUp) в свойстве формы, относящемся к данным, в которых она заинтересована (например, свойство DataInterest).

d. В методах IStylusAsyncPlugin.StylusDown, IStylusAsyncPlugin.Packets и IStylusAsyncPlugin.StylusUp формы добавить код для манипулирования уведомлениями об опускании стило, пакетах и поднятии стило, которые посылаются от объекта стило реального времени формы.

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

Данные пера могут занимать свое собственное пространство имен (например, пространство имен StylusInput.PluginData).

Объект описания свойства планшета (например, объект TabletPropertyDescription) может содержать глобально уникальный идентификатор (ГУИД) свойства и структуру метрик свойства планшета (например, TabletPropertyMetrics), которая описывает диапазон, разрешение и единицы свойства для конкретного планшета.

Может существовать метод, который принимает уникальный идентификатор планшета и возвращает коллекцию объектов описания свойства, поддерживаемых планшетом. Например, метод GetTabletPropertyDescriptionCollection объекта стило реального времени принимает уникальный идентификатор планшета и возвращает коллекцию объектов TabletPropertyDescription, поддерживаемых планшетом. Метод GetDesiredPacketDescription объекта стило реального времени возвращает матрицу ГУИД для свойств пакета, которые объект стило реального времени направляет своим подключаемым модулям.

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

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

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

Нижеследующее описывает подключаемые модули и класс RealTimeStylus. Подключаемые модули, объекты, которые реализуют интерфейс IStylusSyncPlugin или IStylusAsyncPlugin, могут быть добавлены к объекту стило реального времени.

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

Объект стило реального времени может использовать объекты в пространстве имен StylusInput.PluginData для передачи данных пера своим подключаемым модулям. Стило реального времени также захватывает исключительные ситуации, создаваемые подключаемыми модулями. Когда оно так делает, оно может уведомлять подключаемые модули посредством вызова метода IStylusSyncPlugin.Error или IStylusAsyncPlugin.Error.

Нижеследующее описывает данные подключаемых модулей и класс стило реального времени.

Подключаемые модули для стило реального времени могут реализовывать интерфейс или IStylusSyncPlugin, или IStylusAsyncPlugin. Можно реализовывать или можно не реализовывать все методы в стило реального времени.

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

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

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

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

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

Формула изобретения

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

2. Объект визуализатора по п.1, в котором упомянутый компонент включает в себя синхронные и асинхронные интерфейсы.

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

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

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

6. Объект визуализатора по п.1, в котором упомянутый компонент включает в себя входную и выходную очереди.

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

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

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

10. Объект визуализатора по п.1, в котором упомянутые данные создаются планшетом.

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

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

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

14. Способ по п.13, дополнительно содержащий этапы:
временного кэширования упомянутых визуализируемых данных стило.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РИСУНКИ