Эффективное кодирование альтернативных графических наборов

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

 

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

Один примерный вариант осуществления обеспечивает механизм эффективного кодирования графических объектов для отображения на удаленном устройстве для приложения (приложений), запущенных на локальном устройстве посредством определения подходящего механизма кодирования независимо от типа языка графики. Этот механизм предусматривает выполнение приложения (приложений) на локальном устройстве, каждое из которых генерирует графическое отображение - на основе конкретного языка графики - для отображения на удаленном устройстве. Далее принимается набор графики для конкретного языка графики, который включает в себя ресурс (ресурсы) и/или команду (команды), используемые в визуализации по меньшей мере части графического отображения для приложения (приложений). Также принимаются данные кодирования, которые включает в себя информацию для следующего: (1) метаданные, которые описывают содержимое полей в пределах набора графики, используемого для поддержки модулей сжатия данных для более эффективного сжатия набора графики, чем когда набор графики находится в нормальной форме; и/или (2) данные типа кодирования, которые описывают механизм (механизмы) сжатия данных, поддерживаемые удаленным устройством, для выбора типа эффективного сжатия для набора графики. На основе принятых данных кодирования соответствующий механизм кодирования определяется для различных частей набора графики.

Другие примерные варианты осуществления обеспечивают эффективную визуализацию графических объектов на удаленном устройстве отображения для приложения (приложений), запущенных на локальном устройстве посредством определения того, какие ресурсы (если таковые имеются) для приложения должны быть посланы к удаленному устройству. В этом варианте осуществления приложение (приложения) также выполняются на локальном устройстве, каждое из которых генерирует графические отображения для передачи к удаленному устройству. Затем принимается набор графики, который включает в себя ресурс (ресурсы) и/или команду (команды) отображения, который может использоваться для визуализации по меньшей мере части отображения (отображений) графики для приложения (приложений). Также принимаются данные ресурсов, которые включают в себя информацию для следующего: (1) информация состояния доставки для определения того, был ли ресурс (ресурсы), соответствующий набору графики, послан к удаленному устройству и сохранен в центральном кэше для повторного использования независимо от типа сохраненного ресурса; (2) информация поддержки приложения для определения выделенных ресурсов, доступных в настоящее время на удаленном устройстве, для отображения ресурса (ресурсов) на удаленном устройстве для приложения (приложений) без передачи ресурса (ресурсов) от локального устройства; (3) данные ограничения системы для определения того, следует ли постепенно посылать часть (части) ресурса к удаленному устройству таким образом, что ухудшенная версия полного ресурса посылается первой, и обновления, которые улучшают ухудшенную версию, посылаются позже для экономии диапазона рабочих частот или других системных ограничений; и/или (4) информация видимости, которая описывает, могут ли ресурсы, соответствующие набору графики, быть видны в настоящее время пользователю в удаленном устройстве. На основе принятой информации ресурсов часть (части) графического набора выбираются для кодирования.

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

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

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

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

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

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

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

Фиг. 1D иллюстрирует механизм для улучшения чувствительности посредством визуализации с частично посланными ресурсами в соответствии с примерными вариантами осуществления.

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

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

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

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

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

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

Как отмечено ранее, вышеуказанные недостатки удаления графических отображений современных сетей преодолеваются через примерные варианты осуществления, обеспеченные здесь. Например, один вариант осуществления обеспечивает кодирование полей, которое является механизмом, используемым для идентификации полей набора графики для конкретного языка графики таким образом, что идентифицируется общность различных полей по различным языкам графики. После идентификации связанная избыточность или общность, идентифицированная по различным типам данных в пределах полей набора графики, может быть эффективно кодирована. Например, избыточность или общность между полями может быть устранена или эффективно сжата посредством применения одного или нескольких из следующих способов: (1) преобразование полей между машинным форматом и сетевым форматом на основе метаданных или другой информации, обеспеченной для этого поля; (2) кодирование поля в переменную длину (например, кодирование двух/трех/четырех байтов); (3) дельта-кодирование, которое обычно используется для кодирования массивов координат, где точка может быть кодирована как дельта относительно предыдущей точки в массиве, и приращения могут быть представлены меньшим числом байтов, чем абсолютная координата; (4) межпорядковое сжатие, которое используется для кодирования структуры определенного типа на основе предыдущей кодированной структуры того же типа. Отметим, что вышеуказанные механизмы могут в настоящее время применяться в других протоколах (например, протокол удаленного рабочего стола (RDP)); однако варианты осуществления, обеспеченные здесь, расширяют кодирование полей до других графических языков, отличных от интерфейса графических устройств (GDI) - например, информация Обоснования Представления Окон (WPF).

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

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

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

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

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

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

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

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

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

Фиг. 1А иллюстрирует распределенную систему, используемую в удаленном отображении (показе) графической информации для приложений на локальном устройстве. Как показано, приложения 115 могут исполняться на локальном устройстве 105, отображения которого предназначены для удаленного устройства 110. Отметим, что приложением 115 может быть любое из бесчисленных приложений, таких как текстовый редактор, приложение электронных таблиц или любое другое хорошо известное приложение. Далее окружением для удаленного устройства 110 и локального устройства 105 может быть окружение типа представления (например, ранее описанное разделение рабочего стола) или сетевая система, в которой удаленное устройство 110 желает выполнить приложения 115 в локальном устройстве 105, еще видеть и управлять приложениями от удаленного устройства 110 вне сети локального устройства 105. Как таковые, коммуникации между локальным устройством 105 и удаленным устройством 110 могут проходить через любую хорошо известную сеть, как локальную, так и распределенную, например ЛВС, Интернет и т.д.

Независимо от типа приложения или сети, используемой для установления канала связи между локальным устройством 105 и удаленным устройством 110, приложения 115 могут делать вызовы 120 программного интерфейса приложений (API) в соответствии с вводом пользователя, принятого от удаленного устройства 110. Такие API вызовы 120 влияют на графические отображения различных приложений 115. Например, API вызовами 120 может быть минимизация/максимизация отображения приложения 115, перемещение пиктограмм или других ресурсов в пределах этого отображения, или любое число хорошо известных способов взаимодействия и изменения графического отображения для одного или нескольких приложений 115. Конечно, как было бы понятно, необязательно для ввода приходить в форме API вызовов 120 для изменения графических отображений различных приложений 115. Соответственно, API вызовы 120 для влияния на графические отображения различных приложений 115 используются здесь только с иллюстративными целями и не означают ограничение или сужение иным образом охвата вариантов осуществления здесь.

Тем не менее, при использовании таких вызовов 120 API вызовы 120 могут вызывать машину 130 формирования, которая генерирует набор 155 графики, который включает в себя команды 160 отображения и/или различные ресурсы 165. Команды 160 отображения (показа) могут включать в себя такую информацию, как тип ресурса 165, позиционирование в пределах отображения (т.е. х-у координаты), размер и/или форма ресурса 165 или любые другие хорошо известные свойства или операции, используемые для отображения различных ресурсов 165. Ресурсы 165 также могут представлять собой любое количество хорошо известных пиктограмм, текста, глифов, спрайтов, побитовых отображений и других типов изображений. Соответственно, команды 160 отображения и ресурсы 165, описанные здесь, должны широко толковаться для охвата любого количества различных операций, выполняемых на ресурсах, а также любое количество данных изображения, используемых для графических отображений приложений 115.

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

Отметим, что в одном варианте осуществления желательно синхронизировать структуру 178 данных визуализации на локальном устройстве 105 с подобной структурой 185 данных визуализации на удаленном устройстве 110. В этом примере примерные варианты осуществления, обеспеченные здесь, могут эффективно кодировать различные наборы 155 графики для обновления или модификации структуры 185 данных визуализации на удаленном устройстве 110. Следует отметить, однако, что хотя некоторые механизмы, обеспеченные здесь, используются для графических языков, которые поддерживают структуры 178, 185 данных визуализации, другие варианты осуществления равным образом применимы к графическим языкам, которые не поддерживают такие структуры 178, 185 данных визуализации. Фактически, многие из вариантов осуществления, описанные здесь, используются для широкого разнообразия графических языков, включающих в себя, но не ограниченных этим, GDI, WPF, а также другие известные (и потенциально неизвестные) графические языки. Соответственно, следующее обсуждение различных вариантов осуществления должно широко толковаться как применимое по широкому числу графических языков.

Независимо от графического языка, используемого для создания набора 155 графики, отметим, что модуль 150 принятия решения о кодировании обычно работает непосредственно на структурах 178 данных визуализации (т.е. на структуре или дереве формирования данных режима сохранения). Модуль 150 принятия решения о кодировании может послать данные 178 визуализации непосредственно, когда приложение 115 вызывает 120 машину 130 формирования, или может послать данные 178 в более позднее время, когда позволяет сеть. Например, приложение 115 может вызвать 120 машину 130 для создания цикла. Команда 120 может транслировать в прямой вызов в модуле 150 принятия решения о кодировании и позже немедленно закодировала бы эту команду цикла и послала бы ее по проводу. Могла бы быть альтернативная модель, что модуль 150 принятия решения о кодировании уведомляется, что цикл был добавлен к структуре 178 данных визуализации (например, композиционному дереву) и пусть модуль 150 принятия решения о кодировании решает, когда следует послать данные 178. Первая модель может рассматриваться как модель «толкать», тогда как вторая модель может быть моделью «тянуть». Разницей между этими двумя моделями является просто момент, когда модуль 150 принятия решения о кодировании считывает обновления со структур 178 данных визуализации. Хотя обе модели работают, модель «толкать», возможно, более ограничена, чем модель «тянуть». Соответственно, наиболее эффективными механизмами обновления, возможно, является гибрид между этими двумя моделями (т.е. данные 178 заталкиваются в сеть так быстро, насколько позволяет диапазон рабочих частот, но если имеется некоторая сетевая перегрузка, то система примет модель «тянуть», управляемую событиями доступности сети).

Независимо от модели, используемой для передачи данных 178, в одном варианте осуществления модуль 150 принятия решения о кодировании может использовать таблицу 135 кодирования с метаданными 140 набора графики (также называемыми здесь просто «метаданными») для идентификации различных типов полей в пределах набора 155 графики. Например, метаданные могут описывать различные типы полей в пределах набора 160 графики, которые может использовать модуль 150 принятия решения о кодировании для соответствующего решения, как наилучшим образом кодировать различные поля для эффективной передачи команд 160 отображения и ресурсов 165 к удаленному устройству 110. Более конкретно, метаданные 140 могут использоваться для идентификации различных типов структур данных для полей, общих среди множества наборов 155 графики для различных графических языков. Такая информация может затем использоваться для поддержки модулей 175 сжатия данных для более легкого распознавания и соответствующего кодирования различных полей набора 155 графики.

Например, команды 160 отображения могут иметь строки или другие двоичные представления, которые включают в себя тип ресурса, позиционирование (например, х-у координаты), цвет или другую информацию, традиционно хранимую или преобразованную в последовательную форму в машинный формат. Соответственно, метаданные 140 могут использоваться для распознавания этих полей как строки, сохраняемые в машинном формате, которые могут быть затем преобразованы в сетевой формат. Например, координата (или другая строка или двоичное поле) обычно будет поддерживаться как машинное слово в наборе 155 графики на локальном устройстве 105, используемом для визуализации, но машинное слово в большинстве случаев в 2-4 раза больше, чем фактический байтовый размер, необходимый для хранения такой координаты. В этом случае машинное слово следует преобразовать в меньший размер и поместить в сетевой пакет, что дает возможность модулям 175 сжатия данных более эффективно кодировать эти поля перед передачей к удаленному устройству 110.

Отметим, что другие варианты осуществления используют метаданные 140 набора графики для описания других полей и ресурсов в пределах набора 155 графики для идентификации наиболее эффективного механизма для сжатия. Например, модуль 150 принятия решения о кодировании может использовать метаданные 140 для определения типа ресурса 165 для выбора модуля 175 сжатия данных, который может наиболее эффективно сжать такую информацию. Например, некоторые побитовые отображения наилучшим образом сжимаются с использованием механизма кодирования длин серий (группового кодирования) (RLE). Соответственно, метаданные 140 могут использоваться для идентификации ресурсов 165 как побитового отображения, и подходящее RLE может быть выбрано для подходящего кодирования такого ресурса.

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

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

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

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

Отметим, что в структуре GFXMETADATA выше декларируются два типа порядков. Первый тип является типом порядка, который включает в себя два числа с плавающей точкой. Второй тип является массивом, который включает в себя одно целое со знаком, одно целое без знака и один массив координат. Эта метаданные должны быть переданы в модуль 150 принятия решения о кодировании во время инициализации. После инициализации вторая структура (ORDER (порядок)) может использоваться для посылки порядков к кодеру 150. Отметим, что вторая структура (ORDER) не описывает типы, а описывает только значения. Даже в XML представлении можно видеть, что путем расщепления метаданных от второй структуры данных (ORDER) необходимо меньше информации для передачи к модулю 150 принятия решения о кодировании содержания для порядка. Метаданные 140 являются очень статичными, так что имеет смысл передать их один раз. Данные порядка, с другой стороны, являются динамическими данными, и обычно к ним не следует присоединять какую-либо статическую информацию. Такая выгода более заметна при использовании двоичного формата (описанного ниже) как для данных, так и для метаданных вместо XML. Кодер или модуль 150 принятия решения о кодировании может просто взглянуть на тип порядка, и он будет знать на основе описания метаданных, как кодировать эти значения.

Например, другие файлы (например, файл языка описания интерфейсов (IDL)) представляют контракт времени компиляции между кодером 175 или модулем 150 принятия решения о кодировании и машиной 130 формирования. Если этот контракт изменяется, то эти два компонента должны быть повторно компилированы с использованием общего (например, IDL) файла. Использование общего файла гарантирует, что устройства работают на одних и тех же форматах структур двоичных данных. Отметим, однако, что описание данных во время компиляции возможно приведет к более быстрой работе модуля 150 принятия решения о кодировании (описанного выше), так как сам код кодирования будет генерироваться непосредственно из описания данных графики. Тем не менее, описание времени компиляции очень зависит от используемого языка. Например, в С и С++ может использоваться набор макросов для определения примитивов графики. Посредством использования макросов можно определить как структуру машинного формата, так и кодирование или сам сетевой код.

Как только соответствующее сжатие 175 данных кодировало одно или несколько полей в пределах набора 155 графики, эти поля (или набор 155 графики) посылаются к удаленному устройству 110, где они разворачиваются с использованием модуля 180 и повторно генерируются, как показано в наборе 190 графики. Как таковая, машина 195 формирования может использовать их для генерации структуры 185 данных визуализации, которые синхронизированы со структурой 178 данных визуализации на локальном устройстве 105. Далее эта структура 185 данных визуализации может быть затем сформирована таким образом, что драйвер 104 отображения может генерировать подходящее отображение 102, представляющее отображения приложений 115 из локального устройства 105. Соответственно, поскольку пользователь на удаленном устройстве 110 взаимодействует с отображением 102, различные наборы 155 графики могут быть сгенерированы и кодированы, как описано ранее, для синхронизации структур 178, 185 данных визуализации.

В другом примерном варианте осуществления выбранный тип кодирования или модуль 175 сжатия данных может быть основан на поддерживаемых типах кодирования на удаленном устройстве 110. Например, во время инициализации соединения (или в некоторое другое время после этого) типы сжатия данных могут быть согласованы между локальным устройством и удаленным устройством 110. Соответственно, как показано, удаленное устройство 110 посылает поддерживаемые типы 184 кодирования, которые могут быть затем включены в список доступных механизмов 145 кодирования. Этот список доступных механизмов 145 кодирования может быть затем использован модулем 150 принятия решения о кодировании в выборе подходящего модуля 175 сжатия данных для сжатия полей в пределах набора 155 графики, как описано ранее.

Отметим, что, хотя доступные механизмы 145 кодирования согласуются между удаленным устройством 110 и локальным устройством 105 обычно во время подключения, точный механизм сжатия, используемый локальным устройством 105 для сжатия частей набора 155 графики, будет выбран «в полете» во время сжатия. Соответственно, удаленное устройство 110 не будет иметь предварительного знания точного типа сжатия 175 данных, который будет использован. Тем не менее, поскольку поддерживаемые типы 184 кодирования определены заранее, локальное устройство 105 может быть гарантировано, что использование любого такого поддерживаемого типа 184 кодирования может быть обработано удаленным устройством 110. Отметим далее, что список доступных механизмов 145 кодирования может быть также основан на механизмах, доступных также на локальном устройстве 105. Другими словами, необходимо, чтобы модули 175 сжатия данных и модули 180 распаковки данных имели общие типы среди них.

Также отметим, как рассматривается здесь, что может использоваться любой хорошо известный тип механизма кодирования (например, RLE, основанный на MPEG, JPEG, GIF, ZIP, основанный на LZ, JBIG, DejaVu или другой хорошо известный образец или механизм сжатия, основанный на статистике, который является либо форматом сжатия, не допускающим потери, либо форматом сжатия с потерями). Также отметим, что одно или несколько полей в пределах набора 155 графики могут быть кодированы с использованием иерархической связи различных модулей 175 кодирования или сжатия данных для наиболее эффективного сжатия данных для посылки по сети в удаленное устройство 110.

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

Например, первое приложение (например, Приложение 1) 115 может сделать вызов для ресурса «А» 106. Поскольку ресурсы посылаются по сети в удаленное устройство 110, состояние доставки таких ресурсов может храниться в таблице 112 ресурсов (которая в этом случае показывает состояние доставки ресурса «А» 114, как уже переданного). На удаленном устройстве 110 ресурс «А» 106 будет сохранен в центральном кэше 128, как показано в списке ресурсов 118 в нем. Соответственно, в следующий раз, когда приложение 115 пожелает использовать ресурс «А» 106 вместо посылки этого ресурса к удаленному устройству 110, диспетчер 108 ресурсов идентифицирует этот ресурс как уже посланный и просто обеспечит команду 160 отображения с идентификатором 161 ресурса для посылки в удаленное устройство 110. Другими словами, необходимо послать ресурс (в данном случае ресурс «А» 106) один раз на протяжении всего соединения между локальным 105 и удаленным 110 устройствами, и его можно повторно использовать для различных приложений (например, приложения 2, которое также вызывает ресурс «А» 106).

Отметим, что хотя некоторые механизмы кэширования, используемые определенными протоколами (например, RDP) дают возможность кэширования ресурсов, такие кэши обычно разделены на основе типов используемых ресурсов (например, глифов, побитовых отображений, спрайтов и т.д.). Хотя такие механизмы могут быть настолько эффективны, насколько общим является механизм центрального кэширования, обеспеченный здесь, эти подходы являются нерасширяемыми. Путем обеспечения центрального кэша 128 для хранения всех ресурсов 180 данное изобретение расширяет способность использовать такие ресурсы 106 на различные приложения 115 и на различные структуры 178, 185 данных визуализации, которые могут использоваться. Например, общий механизм кэширования, обеспеченный здесь (с использованием, например, RDP), имеет добавочную выгоду посылки ресурса только один раз и использования его различными узлами в композиционной структуре или дереве. Например, если пиктограмма используется множественными приложениями 115, то эта пиктограмма будет присутствовать в каждом из композиционных поддеревьев (или структур 178, 185 данных визуализации), соответствующих этим приложениям 115.

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

В еще одном примерном варианте осуществления обеспечен механизм для улучшения чувствительности путем визуализации с частично посланными ресурсами. В этом примере системное ограничение 116, такое как диапазон рабочих частот или ограничения отображения на удаленном устройстве 110, может быть идентифицировано модулем 150 принятия решения о кодировании, который включает в себя диспетчер 108 ресурсов. На основе таких системных ограничений 116 диспетчер 108 ресурсов может определить, что только частичные ресурсы 163 должны быть посланы в командах 160 отображения для набора 155 графики, как описано ранее. Более конкретно, обычно имеется две части информации, необходимой для визуализации набора 155 графики. Первая часть, показанная здесь как команды 160 отображения, описывает фактические операции визуализации для ресурса 165. Обычно они содержат команды о том, как и какие ресурсы 165 следует использовать для визуализации. Вторая часть представляет ресурс 168, используемый для визуализации.

Как можно видеть, команды 160 визуализации или отображения обычно необходимо послать полностью к клиенту или удаленному устройству 110 перед началом визуализации. Это, однако, не имеет места в случае с ресурсами 165. Ресурс 165 не всегда должен быть 100%-доступным, когда визуализация начинается для чего-либо важного для визуализации приложением 115. Например, начальный ресурс 165 побитового отображения может содержать изображение, сжатое постепенным способом. Например, цвет изображения может быть первоначально неточным из-за различных ограничений диапазона рабочих частот или других рассмотрений. Тем не менее, удаленное устройство может использовать это расплывчатое, бесцветное или ухудшенное иным образом изображение для визуализации на удаленном устройстве.

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

Также отметим, что этот механизм частичной визуализации может хорошо работать для систем режима сохранения, но может не работать также хорошо для других моделей (например, GDI). Причиной является то, что в режиме сохранения как только структура 185 данных визуализации (например, композиционное дерево) обновляется улучшенным ресурсом 165, вся информация на удаленной стороне 110 будет запускать повторное рисование. В других моделях без сохранения (например, в GDI модели), однако, возможно, нет механизма для повторного формирования на удаленной 110 стороне, так что в случае, когда рисование происходит с неточным ресурсом, обычно нет механизмов для обновления рисования до тех пор, пока локальное 105 или сторона сервера не использует этот ресурс 165 опять в операции рисования. Тем не менее, даже в модели без сохранения могут быть случаи, когда предпочтительно визуализировать с использованием неточных ресурсов 165, чем ждать целого ресурса 165 перед визуализацией чего-либо.

Фиг. 1D иллюстрирует вышеуказанный вариант осуществления, использующий массив координат, показанный в кривой 142. Как показано, полный набор 144 ресурсов включает в себя бесчисленные точки вдоль кривой 142. Варианты осуществления, однако, могут использовать системное ограничение 116 для решения, что следует послать только частичный набор 148 ресурсов. Например, только доля точек вдоль кривой 146 посылается в этом примере, который, хотя и не представляет кривую 142 точно, все же дает возможность осуществить разумное изображение всего изображения. Другими словами, точная кривая 142 аппроксимируется из множества точек, причем каждая точка представляет цифровой замер для этой кривой, где чем больше присутствует замеров, тем более точно будет выглядеть кривая. В зависимости от кривой 142, однако, может быть визуализировано достаточно близкое представление 146 с использованием только доли от числа замеров. Остальные точки могут быть обновлены в более позднее время. По мере того, как обновления прибывают от локального устройства 105, удаленное устройство 110 будет обновлять набор точек для этой кривой 142 и повторно визуализировать структуру 185 данных, которая использует его. С каждым обновлением кривая 146 визуализации будет все более приближаться к конечной целевой форме 142.

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

В еще одном примерном варианте осуществления диспетчер 108 ресурсов может определить или идентифицировать те ресурсы, которые выделены как на локальном устройстве 105, так и на удаленном устройстве 110. Соответственно, поддерживаемая информация 122 приложения может быть передана к локальному устройству 105 после инициализации соединения (или в некоторое время после этого). Эта информация обычно будет включать в себя ресурсы 124 приложений, поддерживаемые и хранимые в хранилище 126 ресурсов на удаленном устройстве 110. Эта поддерживаемая информация 122 приложений может быть затем использована диспетчером 108 ресурсов в определении того, какие типы ресурсов должны быть посланы к удаленному устройству 110.

Например, как удаленное 110, так и локальное устройство 105 может иметь установленное конкретное приложение (например, конкретный тип текстового редактора). Соответственно, пиктограммы или другие ресурсы 124 приложения, связанные с ними, будут также помещены на обоих устройствах 105, 110. В этих случаях локальное устройство 105 может просто использовать команду 160 отображения и идентификатор 161 ресурса для инструктирования удаленного устройства 110 использовать соответствующие пиктограммы, без фактической необходимости локальному устройству 105 посылать ресурс 124 для этого. Отметим, однако, что такая модель предполагает, что ресурсы 124 хранятся в последовательной форме. Они могут быть преобразованы как необходимо, но это преобразование обычно имеет место на уровне аппаратного обеспечения. Соответственно, для протоколов или языков графики, которые не преобразуют этот ресурс, можно для локального устройства 105 передать клиенту хорошо известные идентификаторы 161 ресурсов вместо посылки данных для ресурсов 124 по проводу. Такое использование выделенных ресурсов 124 приложения на удаленном устройстве 110 является особенно выгодным в примере, когда размеры ресурса 124 велики.

Следует также отметить, что точный ресурс 124 необязательно находится как на локальном 105, так и на удаленном 110 устройствах. Например, некоторые приложения 115 имеют ресурсы 124, которые являются общими среди нескольких приложений 115. Например, большинство приложений 115 имеют границу, строку заголовка и оконные команды для пиктограмм минимизации/максимизации, полного/частичного экрана и/или закрытия. Как таковые, ресурсы 124 приложения, используемые на удаленном устройстве 110, необязательно нуждаются в соответствии точному приложению 115 на локальной машине 105, хотя обычно это будет случай, когда они нуждаются в этом.

Фиг. 1С показывает использование различных ресурсов, которые могут использоваться или которые выделены как на локальном устройстве 105, так и на удаленном устройстве 110. В этом примере ресурс 132 границы может использоваться для выделения окна отображения приложения. Далее, строка заголовка 135, а также пиктограммы 136 управления окном могут также быть ресурсами 124 приложения, к которым может быть получен доступ и которые могут использоваться на удаленном устройстве 110. Подобным же образом, может также использоваться инструментальная панель 138 с различными компонентами или пиктограммами. Тем не менее, будет необходимо послать информацию, которая подвергается манипуляции и изменена иным образом на локальном устройстве 105, по проводу посредством вариантов осуществления, описанных ранее.

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

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

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

Фиг. 2 иллюстрирует блок-схему для способа 200 эффективного кодирования графических объектов для отображения на удаленном устройстве для приложений, запущенных на локальном устройстве посредством определения подходящего механизма кодирования независимо от типа используемого графического языка. Способ 200 включает в себя акт выполнения 205 приложения (приложений) на локальном устройстве. Например, приложения 115 могут выполняться на локальном устройстве 105, где приложения 115 генерируют графическое отображение - на основе конкретного языка графики - для отображения в удаленном устройстве 110. Такой язык графики может включать в себя GDI, WPF или другие типы известных в настоящее время или будущих графических языков.

Способ 200 также включает в себя акт принятия 210 набора графики для конкретного языка графики. Например, модуль 150 принятия решения о кодировании может принять набор 155 графики для конкретного языка графики, где набор 155 графики включает в себя команду (команды) 160 отображения и/или ресурс (ресурсы) 165. Такие наборы 155 графики будут использоваться для визуализации по меньшей мере части графического отображения для приложений 115 на удаленном устройстве 110. Отметим, что эти команды отображения могут включать в себя свойства, которые описывают ресурс в виде положения на дисплее, размера, цвета, формы и т.д. Далее отметим, что этими ресурсами может быть любой из хорошо известных ресурсов, таких как глифы, пиктограммы, спрайты, побитовые отображения или любое другое изображение.

Кроме того, способ 200 включает в себя акт принятия 220 данных кодирования для: (1) метаданных, которые описывают содержание набора графики; (2) данных типа кодирования, которые описывают механизмы сжатия данных, поддерживаемые удаленным устройством. Например, модуль 150 принятия решения о кодировании может принимать метаданные 140 набора графики, которые описывают содержание полей в пределах набора 155 графики, используемого для помощи модулям 175 сжатия данных в более эффективном сжатии набора 155 графики, когда набор 155 графики имеет нормальную форму. Отметим, что эта нормальная форма может быть в последовательной или непоследовательной форме. Альтернативно, или в сопряжении, модуль 150 может принимать список доступных механизмов 145 кодирования, поддерживаемых удаленным устройством 110. Эти данные типа кодирования будут описывать механизмы сжатия данных, поддерживаемые удаленным устройством 110 для выбора эффективного типа кодирования для набора 155 графики, как описано ранее.

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

Фиг. 3 иллюстрирует способ 300 эффективной визуализации графических объектов на удаленном устройстве отображения для приложений, запущенных на локальном устройстве, путем определения того, какие (если таковые имеются) ресурсы для приложения должны быть посланы к удаленному устройству. Способ 300 включает в себя акт выполнения 305 приложения (приложений) на локальном устройстве. Например, приложения 115 могут выполняться на локальном устройстве 105, каждое из которых генерирует графические отображения для передачи к удаленному устройству 110. Способ 300 также включает в себя акт принятия 310 набора графики, который включает в себя команду (команды) отображения и/или ресурс (ресурсы). Например, модуль 150 принятия решения о кодировании, в сопряжении с диспетчером 108 ресурсов, может принять набор 155 графики, который включает в себя ресурсы 165 и/или команды 160 отображения, которые будут использоваться в визуализации по меньшей мере части графических отображений для приложений 115 на удаленном устройстве 110.

Способ 300 также включает в себя акт принятия 315 данных ресурсов для: (1) информации состояния доставки; (2) информации поддерживаемых приложений; (3) данных системных ограничений; (4) информации видимости. Более конкретно, диспетчер 108 ресурсов может принимать данные ресурсов для определения состояния доставки ресурса 165. Например, таблица 112 состояния ресурсов может использоваться диспетчером 108 ресурсов для определения состояния доставки ресурса, соответствующего набору 155 графики, для определения того, был ли соответствующий ресурс (например, ресурс А114) послан к удаленному устройству 110 и сохранен в центральном кэше 128 с целью повторного использования независимо от типа сохраненного ресурса. Другими словами, ресурсы различных типов хранятся в пределах центрального кэша 128 таким образом, что неоднородные ресурсы будут трактоваться однородным образом при их сохранении. Отметим, что локальное устройство 105 и удаленное устройство 110 могут использовать или могут не использовать механизмы, которые ограничивают фрагментацию памяти, вызванную кэшированием ресурсов с очень разными размерами.

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

Кроме того, модуль 150 принятия решения о кодировании или диспетчер 108 ресурсов может также принимать информацию 116 системных ограничений для определения того, следует ли постепенно посылать части ресурса к удаленному устройству 110 таким образом, что сначала посылается ухудшенная версия полного ресурса, а обновления, которые улучшают эту ухудшенную версию, посылаются позже для экономии диапазона рабочих частот или других системных ограничений. Например, как показано на фиг. 1D, полный набор 144 ресурсов, который показывает кривую 142 с высокой дискретизацией, может быть сначала послан как частичный набор 148 ресурсов, который включает в себя только часть общего набора дискретизации, показанную как кривая 146. Отметим, что частичные ресурсы, которые постепенно посылаются к удаленному устройству, могут включать в себя побитовые отображения, кривые, сетки или другие формы изображений. Также отметим, что ухудшенная версия включает в себя неточности цвета, подробностей, числа точек дискретизации или другое ухудшение качества изображения, но ухудшенная версия ресурса должна включать в себя достаточно информации для того, чтобы дать возможность пользователю в удаленном устройстве 110 распознать этот ресурс. Далее отметим, что ресурсом может быть кнопка, отмечаемая кнопка или другой интерактивный элемент, и пользователь должен быть все же способен взаимодействовать с этим элементом без принятия полного ресурса.

Кроме того, модуль 150 принятия решения о кодировании или диспетчер 108 ресурсов может принимать информацию видимости 113 из таблицы 112 состояния ресурсов, которая описывает, может ли один или несколько ресурсов 165, соответствующие набору 155 графики, быть виден в данное время пользователю. Такая информация видимости может включать в себя информацию о Z-порядке, прозрачности, состоянии минимизации/максимизации ресурса и т.д. Соответственно, ресурсы, которые не могут быть видны, могут быть задержаны при посылке к удаленному устройству 110, пока не позволит диапазон рабочих частот или пока не возникнет необходимость в их виде.

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

Фиг. 4 иллюстрирует способ 400 эффективной синхронизации структур данных визуализации, используемых в генерации графического отображения на удаленном устройстве для приложений, выполняемых в локальном устройстве. Способ 400 включает в себя акт выполнения 405 приложения (приложений) на локальном устройстве. Например, как описано ранее, приложения 115 могут выполняться на локальном устройстве 105, каждое из которых генерирует структуры 178 данных визуализации конкретного языка графики, которые являются структурами данных режима сохранения, которые поддерживают состояние ресурсов 165 и используются для формирования графического отображения для приложений 115 на удаленном устройстве 110.

Способ 400 также включает в себя акт принятия 410 набора графики, который включает в себя ресурс (ресурсы) и/или команду (команды) отображения. Например, модуль 150 принятия решения о кодировании может принимать набор 155 графики, который включает в себя команды 160 отображения и/или ресурсы 165. Команды 160 отображения могут включать в себя свойства, которые описывают ресурс 165 в виде позиционирования на дисплее, размера, цвета, формы и т.д.

Способ 400 также включает в себя акт принятия 114 метаданных, которые включают в себя описание набора графики. Например, модуль 150 принятия решения о кодировании может принимать метаданные 140 набора графики, которые включают в себя описание полей набора 155 графики для помощи модулям 175 сжатия в идентификации типа структуры для полей, общих среди множества наборов 155 графики для различных графических языков, которые модуль 175 сжатия данных может более легко распознать и соответствующим образом кодировать. Например, на основе метаданных 140 эти поля могут быть преобразованы из машинного формата в сетевую форму, которая уменьшает битовую длину этих полей для более хорошего отношения сжатия, чем в машинной форме. Далее, метаданные 140 могут использоваться для кодирования в форму переменной длины или дельта-кодирования, используемого таким образом, что только изменение в ресурсе посылается к удаленному устройству, которое может быть кодировано с использованием меньшего количества байтов, чем при посылке всего набора 155 графики. Кроме того, метаданные 140 могут использоваться для механизма межпорядкового сжатия, используемого для кодирования полей определенного типа на основе ранее кодированной структуры того же самого типа.

Отметим, что метаданные 140 могут быть или могут не быть присоединенными к набору 155 графики. Например, обычно обмен метаданными 140 является одноразовым событием, которое описывает используемые типы набора 155 графики (например, порядки/команды или ресурсы). Затем каждому набору 155 графики может быть задан префикс - тип (или идентификатор). Затем модуль 150 принятия решения о кодировании может взглянуть на этот идентификатор и выбрать подходящий модуль 175 сжатия данных, подходящий порядок кодирования и т.д. на основе первоначально переданных метаданных 155.

На основе принятых метаданных способ 400 включает в себя акт кодирования 420 полей набора графики. Например, модуль 150 принятия решения о кодировании на основе метаданных 140 графического набора, которые описывают поля в пределах набора 155 графики, может использовать эти данные для кодирования полей для посылки к удаленному устройству 105 и синхронизации структур 178, 185 данных визуализации между локальным 105 и удаленным 110 устройствами, которые используются для формирования графического отображения в удаленном устройстве 110 для приложений 115.

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

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

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

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

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

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

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

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

8. Способ по п.7, в котором один или несколько модулей сжатия данных включают в себя одно или несколько из: RLE, основанного на MPEG, JPEG, GIF, ZIP, основанного на LZ, JBIG, DejaVu или другого хорошо известного образца или основанного на статистике механизма сжатия.

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

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

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

12. Способ по п.9, в котором информация видимости включает в себя информацию о Z-порядке, прозрачности или состоянии минимизации/максимизации одного или нескольких ресурсов.

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

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

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

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

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

18. Способ по п.15, в котором на основе метаданных одно или несколько полей кодируют в форму переменной длины.

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

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