MX2008011658A - Codificacion eficiente de grupos de graficos alternativos. - Google Patents

Abstract

Las modalidades proporcionan codificación eficiente y presentación de presentaciones de grafico remoto aplicando uno o más de los siguiente: (1) codificación de campo para identificar campos de un grupo de gráficos de manera que se identifican peculiaridades para varios campos a través de diferentes lenguajes de gráficos; (2) guardar en memoria caché recursos, que trata recursos heterogéneos en una forma homogénea cuando vienen de almacenarlos; (3) determinar el tipo de codificación para artículos remotos dentro de un grupo de gráficos basándose en los tipos de mecanismos de compresión soportados por un dispositivo remoto; (4) mejorar respuesta al presentar recursos parcialmente enviados; (5) un mecanismo para determinar qué porciones (si hay alguna) de un grupo de gráficos debe enviarse un dispositivo remoto y en qué orden; y (6) utilizar recursos dedicados ya en el dispositivo remoto con el fin de eliminar la transferencia de un recurso entre un dispositivo local y el dispositivo remoto cuando se presenta dicho recurso.

Description

CODIFICACION EFICIENTE DE GRUPOS DE GRAFICOS ALTERNATI OS REFERENCIA CRUZADA A SOLICITUDES RELACIONADAS N/A ANTECEDENTES A medida que los sistemas computarizados han crecido en popularidad, así lo han hecho las necesidades de distribuir archivos y procesar recursos de sistema de computadora en redes tanto grandes como pequeñas. En general, los sistemas de computadora y dispositivos relacionados comunican información a través de una red por una variedad de razones, por ejemplo, para intercambiar mensajes electrónicos personales, vender mercancía, proporcionar información de cuenta, y así sucesivamente. Se apreciará, sin embargo, que mientras los sistemas de computadora y sus aplicaciones relacionadas se vuelven crecientemente más sofisticados, los retos asociados con compartir datos y recursos en una red también han crecido. Algunas formas actuales para distribuir recursos dentro de una red de organización pueden involucrar un servicio centralizado (o dispositivo local) que comparte recursos con uno o más clientes (o dispositivos remotos) que típicamente no tienen tales recursos ¡ocalmente instalados. Tales sistemas normalmente utilizan un protocolo dedicado tal como Protocolo de Escritorio Remoto ("RDP"), Arquitectura de Cómputo Independiente (ICA), y otros, y comparten varias aplicaciones con un cliente remoto. Con tales protocolos, un sistema de computadora de cliente puede acceder a un servidor centralizado, el cual aloja recursos de interés, e interactúa (por ejemplo, enviar eventos de ratón y teclado, etc.) con aquellos recursos justo aunque se instalaron localmente esos recursos. Un servidor de red a su vez, procesa esas interacciones, crea información de presentación correspondiente de los datos, y envía tanto los datos procesados como la información de presentación creada de regreso al cliente. El sistema de computadora de cliente entonces recibe los datos y presenta información, y utiliza un controlador de video de lado de cliente para presentar y exhibir los datos recibidos localmente. Idealmente, esta interacción entre el sistema de computadora de cliente y el servidor de red ocurre uniformemente aunque el sistema de computadora de cliente realmente procesó los datos localmente con sus propios recursos instalados. Desafortunadamente, tales sistemas pueden someterse a limitaciones de salida de red, que, si se sobrecargan, puede resultar en un "retraso" entre lo que el sistema de computadora de cliente local de en término de interacción y procesamiento. Otro tipo de sistema que es similar en muchos aspectos al modelo de participación centralizado descrito anteriormente involucra un sistema de computadora de cliente de difusión (o "envío") configurado para enviar información de datos de ventana a otros sistemas de computadora de cliente de recepción en una red. Este aspecto algunas veces se llama "participación de escritorio". En este ejemplo, la computadora de difusión (por ejemplo, un "instructor" en un ambiente de aprendizaje) y los sistemas de computadora de recepción (por ejemplo, "estudiantes") se conectan utilizando un programa de aplicación comúnmente instalado que permite la participación de vistas de escritorio y aplicaciones localmente instaladas en la computadora de instructor. Similar al escenario de sistema de cómputo centralizado, los sistemas de computadora de cliente pueden ser capaces de interactuar con las ventanas presentadas en la computadora de instructor aunque las ventanas fueran de la computadora de estudiante. Debido a que los mapas de bits son costosos en término de consumo de ancho de banda cuando se transmiten en una conexión de red (por ejemplo, Internet), en lugar de enviar los mapas de bits completos la mayoría de los sistemas de hoy en día (tal como aquellos descritos anteriormente) envían primitivos de gráficos y otras operaciones, que le dicen a la sub-rutina en el lado de cliente cómo y qué dibujar. Por ejemplo, un cliente puede recibir la instrucción de dibujar un rectángulo junto con la información sobre en donde la debe dibujar, que tamaño, color, etc. Por ejemplo, un rectángulo puede utilizarse para dibujar un botón para una interfase de usuario, un borde alrededor de un documento, o cualquier otro propósito para el cual puede ser útil la forma rectangular. Por supuesto, existen muchas otras formas y operaciones que pueden utilizarse como primitivos que pueden ser más sofisticados y requerir más procesamiento que debe hacerse para transferir y realizar la operación en el cliente remoto. Aunque el uso anterior de primitivos ha mejorado la uniformidad de sistemas de red, mientras las aplicaciones continúan obteniendo inferíase de gráficos más sofisticadas y otras presentaciones, entre más procesamiento, el uso de los primitivos anteriores se vuelve más intensivo. Además, la información enviada del dispositivo local al remoto para presentar gráficos en la presentación en el cliente típicamente se utiliza en un modo de presentación inmediato en donde resultan ventanas con mosaico en la pérdida de información de gráficos. Por ejemplo, al utilizar el modo de presentación inmediato, sólo la información necesaria para dibujar las porciones visibles de las ventanas está disponible. En otras palabras, no hay información de gráficos retenida para porciones de ventanas en el fondo cubierto por otras ventanas, es decir, la información de gráficos sólo se retiene para la ventana de nivel superior. Por consiguiente, cuando se mueve una ventana hacia adelante, se necesita nueva información para dibujar la ventana. Debido al aumento notado anteriormente en sofisticación de gráficos, este envío continuo de información puede sobrecargar el sistema cuando se necesitan actualizaciones frecuentes, por ejemplo, cuando las ventanas se desordenan, giran, y reordenar. Esto también presenta varios retos ya que se relaciona con animaciones más sofisticadas.

BREVE DESCRIPCION DE LA INVENCION Las deficiencias antes identificadas y desventajas de redes actuales se superan a través de modalidades ilustrativas de la presente invención. Por ejemplo, las modalidades aquí descritas proporcionan mecanismos utilizados para codificar y utilizar eficientemente recursos para aplicaciones ejecutadas en un dispositivo local, incluso presentadas en dispositivo remoto. Se debe notar que esta breve descripción se proporciona para introducir una selección de conceptos en una forma simplificada que además se describe posteriormente en la descripción detallada. Esta breve descripción no pretende identificar características clave o características esenciales del tema reclamado, ni pretende utilizarse como un auxiliar al determinar el alcance del tema reclamado. Una modalidad ilustrativa proporciona un mecanismo para eficientemente codificar objetos de gráficos para presentación en un dispositivo remoto para aplicación(es) que corren en un dispositivo local al determinar un mecanismo de codificación apropiados sin importar el tipo de lenguaje de gráficos utilizado. El mecanismo proporciona aplicación(es) de ejecución en un dispositivo local, cada una de las cuales genera la presentación de gráficos, basándose en un lenguaje de gráficos particular, para presentación en un dispositivo remoto. Además, se recibe un grupo de gráficos para un lenguaje de gráficos particular. que incluye recurso(s) y/o comando(s) utilizado al presentar al menos una porción de la presentación de gráficos para la aplicación(es). También se reciben los datos de codificación que incluyen información para lo siguiente: (1) metadatos que describen los contenidos de campos dentro del grupo de gráficos utilizado para ayudar a los módulos de compresión de datos a comprimir más eficientemente el grupo de gráficos que cuando el grupo de gráficos está en forma normal; y/o (2) codificar datos de tipo que describen mecanismo(s) de compresión de datos soportados por el dispositivo remoto para seleccionar un tipo de compresión eficiente para el grupo de gráficos. Basándose en los datos de codificación recibidos, se determina un mecanismo de codificación apropiado para varias porciones del grupo de gráficos. Otras modalidades ilustrativas proporcionan presentación eficiente de objetos de gráficos en un dispositivo de presentación remoto para aplicación(es) que corren en un dispositivo local al determinar que (si hay alguno) recursos deben enviarse para la aplicación al dispositivo remoto. En esta modalidad, la aplicación(es) también se ejecuta en un dispositivo local, cada una de las cuales genera presentaciones de gráfico para transmitirse a un dispositivo remoto. Un grupo de gráficos que incluye recurso(s) y/o comando(s) de presentación entonces se recibe, que puede utilizarse para presentar al menos una porción de la presentación(es) de gráficos para la aplicación(es) . También se reciben datos de recurso que incluyen información para lo siguiente: (1) entregar información de estado para determinar si el recurso(s) que corresponde al grupo de gráficos se envía al dispositivo remoto y se almacenó en una memoria caché central para propósitos de reutilización con respecto al tipo de recursos almacenados; (2) información de aplicación soportada para determinar recursos dedicados actualmente disponibles en el dispositivo remoto con el fin de presentar recurso(s) en el dispositivo remoto para las aplicación(es) sin transferir el recurso(s) del dispositivo local; (3) datos de limitación de sistema para determinar si la porción(es) de un recurso debe enviarse progresivamente al dispositivo remoto para que una versión degradada del recurso completo primero se envíe primero y actualice que mejora de la versión degradada se envía subsecuentemente para guardar ancho de banda u otras limitaciones de sistema; y/o (4) información de visibilidad que describe si los recursos correspondientes al grupo de gráficos pueden o no verse actualmente por un usuario en el dispositivo remoto Basándose en la información de recurso recibida, la porción(es) del grupo de gráficos se selecciona para codificación. Otra modalidad ilustrativa proporciona presentar en sincronización eficientemente estructuras de datos utilizadas al generar una presentación de gráficos en un dispositivo remoto para aplicaciones ejecutadas en un dispositivo local. En esta modalidad, similar a otras modalidades, la aplicación(es) se ejecutan en un dispositivo local, cada una de las cuales genera estructura(s) de datos de presentación de un lenguaje de gráficos particular, que retienen estructuras de datos de modo que mantienen el estado de recurso(s) y se utilizan para componer una presentación de gráficos para la aplicación(es) en un dispositivo remoto. Después de eso, se recibe un grupo de gráficos que incluye recurso(s) y/o comando(s) de presentación que corresponde al lenguaje de gráficos particular y se utiliza para modificar la estructura(s) de datos de presentación. Además, los metadatos se reciben e incluyen una descripción de campos para el grupo de gráficos con el fin de ayudar al módulo(s) de compresión de datos a identificar un tipo de estructura para los campos comunes entre grupos de gráficos para diferentes leguajes de gráficos que el módulo(s) de compresión de datos puede reconocer más fácilmente y codificar apropiadamente. Basándose en los metadatos recibidos, los campos de grupo de gráficos se codifican para enviar a un dispositivo remoto y sincronizar estructura(s) de datos de presentación entre los dispositivos locales y remotos, que se utilizan para componer una presentación de gráficos en el dispositivo remoto para la aplicación(es). Además, los metadatos se reciben e incluyen una descripción de campos para el grupo de gráficos con el fin de ayudar al módulo(s) de compresión de datos a identificar un tipo de estructura para los campos comunes entre grupos de gráficos para diferentes lenguajes de gráficos que el módulo(s) de compresión de datos puede reconocer más fácilmente y codificar apropiadamente. Basándose en los metadatos recibidos, los campos de grupo de gráficos se codifican para enviar a un dispositivo remoto y sincronizar estructura(s) de datos de presentación entre los dispositivos locales y remotos, que se utilizan para componer una presentación de gráficos en el dispositivo remoto para la aplicación(es). Características y ventajas adicionales de la invención se mencionarán en la descripción que sigue, y en parte serán obvias a partir de la descripción, o pueden aprenderse por la práctica de la invención. Las características y ventajas de la invención pueden realizarse y obtenerse por medio de los instrumentos y combinaciones particularmente señaladas en las reivindicaciones anexas. Estas y otras características de la presente invención serán más completamente evidentes a partir de la siguiente descripción y reivindicaciones anexas, o pueden aprenderse por la práctica de la invención como se menciona aquí posteriormente.

BREVE DESCRIPCION DE LOS DIBUJOS Con el fin de describir la forma en la cual las características antes mencionadas y otras ventajosas de la invención pueden obtenerse, una descripción más particular de la invención brevemente descrita anteriormente se presentará por referencia a las modalidades específicas de la misma que se ilustran en los dibujos anexos. Se debe entender que estos dibujos ilustran solo modalidades típicas de la invención y por lo tanto no deben considerarse que limiten su alcance, la invención se describirá y explicará con especificación adicional y detalle a través del uso de los dibujos anexos en donde: La Figura 1A ilustra un sistema distribuido que utiliza información variada para codificar eficientemente grupos de gráficos utilizados al presentar una presentación en un dispositivo remoto de acuerdo con varias modalidades ilustrativas; La Figura 1B ilustra un sistema distribuido que utiliza información sobre varios recursos para determinar que porciones de recursos (si hay alguna) debe codificase para transmisión a un dispositivo remoto de acuerdo con modalidades ilustrativas; La Figura 1C ilustra algunos de los recursos o iconos dedicados que pueden estar disponibles en un dispositivo remoto y utilizarse para que no haya transferencia de los recursos desde un dispositivo local de acuerdo con modalidades ilustrativas; La Figura 1 D ilustra un mecanismo para mejorar la respuesta al presentar con recursos parcialmente enviados de acuerdo con modalidades ilustrativas; La Figura 2 ilustra un diagrama de flujo para un método para presentar eficientemente objetos de gráficos para presentación en un dispositivo remoto de acuerdo con modalidades ilustrativas; La Figura 3 ilustra un diagrama de flujo para un método para presentar eficientemente objetos de gráficos en un dispositivo de presentación remoto de acuerdo con modalidades ilustrativas; y La Figura 4 ilustra un diagrama de flujo para un método de sincronizar eficientemente estructuras de datos de presentación utilizadas al generar una presentación de gráficos en un dispositivo remoto de acuerdo con modalidades ilustrativas.

I 1 DESCRIPCION DETALLADA La presente invención se extiende a métodos, sistemas, y productos de programa de computadora para eficientemente colocar el remoto grupo de gráficos utilizados al presentar la presentación de la aplicación(es) local en un dispositivo remoto. Las modalidades de la presente invención pueden comprender una computadora de propósito especial o de propósito general que incluye varios hardwares de computadora o módulos, como se discutió en mayor detalle posteriormente. Como un tema preliminar, se apreciará y entenderá que los ejemplos y descripciones aquí hacen referencia a la terminología de MICROSOFT™ para propósitos de conveniencia en varias ¡mplementaciones. Tales referencias a términos específicos, sin embargo, no deben interpretarse como limitando las modalidades aquí para operación específica u otros sistemas de tipo. En lugar de eso, la funcionalidad elemental descrita aquí puede practicarse en cualquier ambiente de cómputo o sistema de operación en donde la funcionalidad aquí descrita se desea. Como se mencionó previamente, las deficiencias y desventajas antes identificadas para presentaciones de gráficos remotos de redes actuales de superan a través de modalidades ilustrativas aquí proporcionadas. Por ejemplo, una modalidad proporciona codificación de campo, que es un mecanismo utilizado para identificar campos de un grupo de gráficos para un lenguaje de gráficos particular tal como peculiaridades de varios campos a través de diferentes lenguajes de gráficos se identifica. Una vez identificada, la redundancia asociada o peculiaridad identificada a través de los varios tipos de datos dentro de los campos de un grupo de gráficos puede codificarse eficientemente. Por ejemplo, la redundancia o peculiaridad entre campos puede eliminarse o comprimirse eficientemente al aplicar una o más de las siguientes técnicas. (1) conversión de campos entre formato de máquina y formato de red basado en metadatos u otra información proporcionada para el campo, (2) codificación de un campo en una longitud variable (por ejemplo, codificación de dos/tres/cuatro bytes); (3) codificación delta, que típicamente se utiliza para codificar órdenes de coordenadas en donde puede codificarse un punto como un delta relativo al punto previo en el orden y deltas pueden representarse en menos bytes que la coordenada absoluta; (4) compresión de inter-orden, que se utiliza para codificar una estructura de cierto tipo basándose en estructura codificada previa del mismo tipo. Se nota que los mecanismos anteriores pueden aplicarse actualmente en otros protocolos (por ejemplo, Protocolo de Escritorio Remoto (RDP)); sin embargo las modalidades aquí proporcionadas se extienden al campo de codificar a otros lenguajes de gráficos diferentes a Interfase de Diseño Gráfica (GDI), por ejemplo, información de Fundación de Presentación de Windows (WPF). En otra modalidad, se proporciona caché de recurso tal como recursos heterogéneos que pueden tratarse en una forma homogénea cuando vienen a clasificarlos. Aunque el mecanismo actual (tal como RDP) permite almacenar recursos en un cliente para guardar ancho de banda al utilizarlos en operaciones posteriores o comandos, la presente invención extiende el mecanismo de guardado en memoria caché para uso en otros lenguajes de gráficos (por ejemplo, diferente a GDI similar a WPF). Por ejemplo, los mecanismos actuales almacenan los tipos de recursos (por ejemplo, grabados, mapas de bits, objetos móviles, etc.) en memorias caché separadas, con lo cual proporciona un acercamiento no extensible para reutilización de recursos. Por consiguiente, las modalidades proporcionan un mecanismo más genérico y extensible que proporciona una memoria caché central para todos los recursos, sin importar su tipo. Como tal, el recurso puede utilizarse múltiples veces dentro de una estructura de datos de presentación o incluso a través de estructuras de datos para diferentes aplicaciones, y de esa forma el recurso solo necesitará enviarse una vez al dispositivo remoto y utilizarse a través de varias sub-estructuras de composición (por ejemplo, un sub-árbol) . Incluso en otra modalidad, el tipo de codificación o compresión para recursos remotos u otros artículos dentro de un grupo de gráficos puede determinarse basándose en los tipos de mecanismos de compresión soportados por el dispositivo remoto. En tal caso, los mecanismos de compresión disponibles pueden negociarse entre el cliente (es decir, dispositivo remoto) y el servidor (es decir, dispositivo local) en tiempo de conexión; sin embargo, el mecanismo de compresión exacto utilizado por el servidor para comprimir un recurso se decidirá al momento de compresión por el dispositivo local. Por consiguiente, el dispositivo local elijará uno de los formatos negociados basándose en que también cada formato comprime los datos dados. Por ejemplo, un tipo de compresión puede tener varias técnicas de compresión utilizadas en un recurso individual. El mecanismo de compresión resultante que reduce muy eficientemente la cantidad de datos entonces puede utilizarse para enviar el recurso (u otros datos) al dispositivo remoto. Se debe notar que el servidor local puede elegir un formato de compresión sin pérdida o con pérdida basándose en los varios recursos u otros datos para comprimir. Incluso otras modalidades ilustrativas proporcionan mejora de respuesta al presentarse con recursos parcialmente enviados. Por consiguiente, basándose en varias limitaciones de sistema tal como ancho de banda o limitaciones de dispositivo de presentación, las porciones de un recurso pueden enviarse junto con los comandos de presentación completa para presentar algo significativo por la aplicación. Por ejemplo, los mapas de bits u otros recursos pueden contener una imagen comprimida con tal técnica progresiva. En tal caso, la imagen de color puede inicialmente ser inexacta debido a que no todos los datos necesarios para descomprimir la imagen completa llegaron al cliente. El dispositivo remoto, sin embargo, puede utilizar una imagen borrosa u otra imagen degradada para una presentación inicial.

A manera de ejemplo, un botón para una aplicación puede tener un color que es vastamente inexacto, incluso que presenta el botón en una forma suficientemente buena para permitir que un usuario interactúe con el botón sin esperar una versión final del mismo. Mientras más datos para la imagen llegan de la red, el dispositivo remoto puede actualizar la imagen y volver a presentar la porción de la estructura de datos que contiene la imagen. Esta forma, la respuesta percibida del usuario dramáticamente aumenta justo debido a que en la mayoría de los casos el usuario puede utilizar la aplicación sin todos los datos de imagen que se actualizan. Se debe notar que se utilizó el uso de un mecanismo de degradación de color; sin embargo, cualquier clase de codificación progresiva o técnica de entrelazamiento puede utilizarse también. Se debe notar además, que tal mecanismo progresivo o de entrelazamiento puede aplicarse no solo a mapas de bits u otros recursos similares, sino también trabajará bien para imágenes con varias órdenes tal como curvas o mallas. Incluso en otra modalidad ilustrativa, se proporciona un mecanismo para determinar que porciones (si hay alguna) de un grupo de gráficos debe enviarse a un dispositivo remoto y en qué orden. Por ejemplo, frecuentemente las porciones de una presentación de gráficos o recurso pueden también no estar visibles para un usuario. Por consiguiente, tales cosas como el Orden Z, transparencia, el estado de minimizar/maximizar, juegan un papel efectivo al determinarse una aplicación o recurso del mismo producirá una salida que es visible para el usuario. Mientras una aplicación o recurso del mismo no es visible, puede ser necesario colocar en remoto el contenido o recurso de la aplicación hasta un tiempo posterior. Por consiguiente, pueden retrasarse las actualizaciones hasta que lo permita el ancho de banda. Además, el servidor local puede poner en prioridad que porciones de las estructuras de datos de presentación o presentaciones se enviarán al dispositivo remoto basándose en tal información de visibilidad. Incluso otras modalidades proporcionan el uso de recursos dedicados en el dispositivo remoto con el fin de eliminar la transferencia de un recurso entre el dispositivo local y el dispositivo remoto cuando presenta tales recursos. Por ejemplo, en la mayoría de los casos en donde se ponen en remoto datos de gráficos, recursos como bordes, barras de título, y/o otros iconos están presentes tanto en el servidor y/o en la computadora remota. Por ejemplo, tanto en el servidor remoto como local tienen la misma (o similar) aplicación instalada, probablemente los iconos para la aplicación local presentarán en la porción de recurso del binario para la aplicación en el lado remoto. En tales casos, el dispositivo local puede ser capaz de instruir al dispositivo remoto a utilizar estos varios recursos, sin el servidor o dispositivo local que tiene que enviar los bytes de recursos para este. Aunque se describe una referencia más específica a características ventajosas en mayor detalle posteriormente con respecto a las figuras, las modalidades dentro del alcance de la presente invención también incluyen medios legibles por computadora para transportar o tener instrucciones ejecutables por computadora o estructuras de datos almacenadas en el. Tales medios legibles por computadora puede ser cualquier medio disponible que puede accederse por una computadora de propósito general o de propósito especial. A manera de ejemplo, y no de limitación, tales medios legibles por computadora pueden comprender RAM , ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que puede utilizarse para transportar o almacenar medios de código de programa deseado en la forma de instrucciones ejecutables por computadora o estructuras de datos y que pueden accederse por la computadora de propósito general o de propósito especial. Cuando se transfiere o proporciona información a través de una red u otra conexión de comunicaciones (ya sea por cable duro, inalámbrico, o una combinación de cable duro o inalámbrico) a una computadora, la computadora observa apropiadamente la conexión como un medio legible por computadora. De esa forma, cualquier conexión se denomina apropiadamente un medio legible por computadora. Las combinaciones de los anteriores también deben incluirse dentro del alcance de medios legibles por computadora. Las instrucciones ejecutables por computadora comprenden, por ejemplo, instrucciones y datos que causan que una computadora de propósito general, computadora de propósito especial, o dispositivo de procesamiento de propósito especial realice cierta función o grupo de funciones. Aunque el tema se describió en lenguaje específico a características estructurales y/o actos metodológicos, se debe entender que el tema definido en las reivindicaciones anexas no necesariamente se limita a las características o actos específicos descritos anteriormente. En lugar de eso, las características y actos específicos descritos anteriormente se describen como formas ilustrativas para implementar las reivindicaciones. Como se utiliza aquí, el término "módulo" o "componente" puede referirse a objetos de software o rutinas que se ejecutan en el sistema de cómputo. Los diferentes componentes, módulos, máquinas, y servicios aquí descritos pueden implementarse como objetos o procedimientos que se ejecutan en el sistema de cómputo (por ejemplo, como secuencias separadas). Mientras los sistemas y métodos aquí descritos preferiblemente se implementan en software, las implementaciones en hardware o una combinación de software y hardware también son posibles y se contemplan. En esta descripción, una "entidad de cómputo" puede ser cualquier sistema de cómputo como se describió aquí previamente, o cualquier módulo o combinación de módulos que corren en un sistema de cómputo. La Figura 1A ilustra un sistema distribuido utilizado al presentar remotamente información de gráfico para aplicaciones en un dispositivo local. Como se muestra, las aplicaciones 115 pueden ejecutarse en dispositivo local 105, que las presentaciones se pretenden para el dispositivo remotos 110. Se debe notar que las aplicaciones 115 puede ser cualquiera de numerosas aplicaciones tal como editor de texto, aplicación de hoja de cálculo o cualquier otra aplicación bien conocida. Además, el ambiente para el dispositivo remotos 110 ó dispositivo local 105 puede ser un ambiente de tipo de presentación (por ejemplo, la participación de escritorio previamente descrita) o sistema de red en el cual un dispositivo remoto 110 desea a ejecutar las aplicaciones 115 en el dispositivo local 105, incluso observar y controlar las aplicaciones desde el dispositivo remoto 110 fuera de la red de dispositivo local 105. Como tal, las comunicaciones entre el dispositivo local 105 y el dispositivo remoto 110 pueden atravesar cualquier red bien conocida, tanto local y distribuida, por ejemplo, una LAN, Internet, etc. Sin importar el tipo de aplicación o red utilizada para establecer un canal de comunicación entre el dispositivo local 105 y dispositivo remoto 110, las aplicaciones 115 pueden hacer llamadas de interfase de programa de aplicación (API) 120 de acuerdo con la entrada de usuario recibida del dispositivo remoto 110. Tales llamadas de API 120 afectan las presentaciones de gráficos de las varias aplicaciones 115. Por ejemplo, las llamadas de API 120 pueden ser para minimizar/maximizar la presentación de una aplicación 115, mover iconos u otros recursos dentro de la presentación, o cualquier número de formas bien conocidas de interactuar y cambiar la presentación gráfica para una o más aplicaciones 115. Por supuesto, como se debe reconocer, no es necesario para una entrada venir en la forma de llamadas de API 120 con el fin de las presentaciones de gráficos de las varias aplicaciones 115 cambien. Por consiguiente, el uso de llamadas de API 120 para afectar las presentaciones de gráficos de las varias aplicaciones 115 se utiliza aquí para propósitos ilustrativos solamente y no significa que limite o de otra forma estreche el alcance de las modalidades aquí. Sin importar cuando se utilizan tales llamadas 120, las llamadas de API 120 pueden llamar en la máquina de composición 130, lo que genera el grupo de gráficos 155 que puede incluir comandos de presentación 160 y/o varios recursos 165. Los comandos de presentación 160 pueden incluir tal información como el tipo de recurso 165, que se coloca dentro de la presentación (es decir, coordenadas x-y), tamaño y/o forma del recurso 165, o cualquier otra de las propiedades u operaciones bien conocidas utilizadas para presentar varios recursos 165. Los recursos 165 también pueden representar cualquier número de iconos bien conocidos, texto, grabados, objetos móviles, mapas de bits, y otros tipos de imagen. Por consiguiente, los comandos de presentación 160 y recursos 165 como se describe aquí deben interpretarse ampliamente para cubrir cualquier número de varias operaciones realizadas en recursos así como cualquier número de datos de imagen utilizados para presentaciones gráficas de aplicaciones 115. El grupo de gráficos 155 típicamente se utiliza para generar estructuras de datos de presentación 178 para las varias aplicaciones 115. A su vez, las estructuras de datos de presentación 178 se utilizan para describir la presentación de una aplicación 115 y puede ser una estructura similar a árbol, en donde cada nodo representa un recuso, propiedad, o descripción relacional del mismo. Por ejemplo, un nodo dentro del árbol de datos pueden representar un botón, mientras otros nodos describen color, tamaño, forma, u otras propiedades del botón, mientras incluso otros nodos representan la relación e interacción con otros componentes o recursos dentro de la presentación de una aplicación 114. Por consiguiente, como se puede reconocer, el grupo de gráficos 155, puede utilizarse para modificar, generar, o de otra forma actualizar la estructura de datos de presentación 178, que después pueden utilizarse para componer una o más presentaciones que corresponden a aplicaciones 115. Se debe notar que diferente a los modos de presentación inmediatos u otros lenguajes de gráficos descritos anteriormente, el uso de las estructuras de datos de presentación 178, 185 permiten un modo de retención, en donde el estado para los recursos se mantiene. Como se describirá en mayor detalle posteriormente, esto junto con otras modalidades aquí descritas permite muchas características ventajosas. Se debe notar que en una modalidad, es deseable sincronizar la estructura de datos de presentación 178 en el dispositivo local 105 con aquella de una estructura de datos de presentación similar 185 en el dispositivo remoto 110 lateral En tal caso, las modalidades ilustrativas aquí proporcionadas pueden codificar eficientemente los varios grupos de gráficos 155 para actualizar modificación de la estructura de datos de presentación 185 en el dispositivo remoto 110. Sin embargo, se debe notar que aunque algunos mecanismos aquí proporcionados se utilizan para lenguajes gráficos que soportan estructuras de datos de presentación 178, 185, otras modalidades son igualmente aplicables a lenguajes gráficos que no soportan tales estructuras de datos de presentación 178, 185. De hecho, muchas de las modalidades aquí descritas se utilizan para una amplia variedad de lenguajes gráficos que incluyen, pero no se limitan a GDI WPF, así como otros lenguajes gráficos conocidos (y potencialmente desconocidos). Por consiguiente, la siguiente discusión de varias modalidades debe interpretarse ampliamente para ser aplicable a través de un gran número de lenguajes gráficos. Sin importar el lenguaje gráfico utilizado para crear el grupo de gráficos 155, se debe notar que el módulo de decisión de codificación 150 típicamente opera directamente en las estructuras de datos de presentación 178 (es decir, estructuras de datos de composición de modo retenido o árbol). El módulo de decisión de codificación 150 puede enviar los datos de presentación 178 inmediatamente cuando una aplicación 115 llama 120 en la máquina de composición 130 ó puede enviar los datos 178 en un momento posterior cuando lo permite la red Por ejemplo, la aplicación 115 puede llamar 120 en la máquina 130 para crear un círculo. El comando 120 puede traducir la llamada directa en el módulo de decisión de codificación 150 y el posterior puede codificar inmediatamente el comando de círculo y enviarlo en el cable. Un modelo alternativo puede ser que se notifica el módulo de decisión de codificación 150 que un círculo se agregó a la estructura de datos de presentación 178 (por ejemplo, un árbol de composición) y permitir que el módulo de decisión de codificación 150 decida cuando los datos 178 deben enviarse. El primer modelo puede considerarse un modelo de "empuje", mientras el segundo puede ser un modelo de "jalar". La diferencia entre los dos es simplemente el momento cuando el módulo de decisión de codificación 150 recoge la actualización de las estructuras de datos de presentación 178. Mientras ambos modelos trabajan, el modelo de empuje puede ser más limitado que el modelo para jalar. Por consiguiente, el mecanismo de actualización más eficiente puede ser un híbrido entre los dos (es decir, los datos 178 se empujan a la red tan rápido como lo permite el ancho de banda, pero si existe alguna congestión de red el sistema adoptará un modelo para jalar conducido por los eventos de disponibilidad de red). Sin importar el modelo utilizado para transferir los datos 178, en una modalidad, el módulo de decisión de codificación 150 puede utilizar una tabla de codificación 135 con metadatos de grupo de gráficos 140 (también denominada aquí solo como "metadatos") para identificar los varios tipos de campos dentro de un grupo de gráficos 155. Por ejemplo, los metadatos 140 pueden describir varios tipos de campos dentro del grupo de gráficos 160, que el módulo de decisión de codificación 150 puede utilizar para decidir apropiadamente como codificar mejor los varios campos para transferencia eficiente de comandos de presentación 160 y recursos 165 al dispositivo remoto 110. Más específicamente, los metadatos 140 pueden utilizarse para identificar diferentes tipos de estructuras de datos para campos comunes entre la pluralidad de grupos de gráficos 155 para diferentes lenguajes de gráficos. Tal información entonces puede utilizarse para ayudar a los módulos de compresión de datos 175 a reconocer más fácilmente y codificar apropiadamente los diferentes campos del grupo de gráficos 155. Por ejemplo, los comandos de presentación 160 pueden ser secuencias u otras representaciones binarias que incluyen el tipo de recurso, colocar (por ejemplo, coordenadas x-y), color, u otra información tradicionalmente almacenada o señalizada en formato de máquina. Por consiguiente, los metadatos 140 pueden utilizarse para reconocer estos campos como secuencias que se almacenan en el formato de máquina, que entonces pueden convertirse en un formato de red. Por ejemplo, una coordenada (u otra secuencia o campo binario) típicamente se mantendrá como una palabra de tamaño de máquina en el grupo de gráficos 155 en el dispositivo local 105 utilizado para presentación, pero una palabra del máquina en la mayoría de los casos dos a cuatro veces mayor que el tamaño de byte actual necesario para almacenar tal coordenada. En tal caso, la palabra de máquina debe convertirse a un tamaño más pequeño y colocarse en el paquete de red, con lo cual permite que los módulos de compresión de datos 175 codifiquen más eficientemente estos campos precio previo a la transmisión al dispositivo remoto 110. Se debe notar que otras modalidades utilizan los metadatos de grupo de gráficos 140 para describir otros campos o recursos dentro del grupo de gráficos 155 para identificar el mecanismo más eficiente para compresión. Por ejemplo, codificar el módulo de decisión 150 puede utilizar los metadatos 140 para determinar el tipo de recursos 165 con el fin de elegir un módulo de compresión de datos 175 que comprime muy efectivamente tal información. Por ejemplo, algunos mapas de bits se comprimen mejor al utilizar un mecanismo de codificación de longitud de funcionamiento (RLE). Por consiguiente, los metadatos 140 pueden utilizarse para identificar un recurso 165 como un mapa de bits y un RLE apropiado puede elegirse para codificar apropiadamente tal recurso. Por supuesto, pueden existir otros tipos de recursos 165 y campos para presentar comandos 160 que pueden identificarse y codificarse apropiadamente basándose en los metadatos de grupo de gráficos 140 proporcionado. Por ejemplo, un campo puede identificarse como codificar mejor en formato de longitud variable, mientras otro puede adecuarse mejor para una codificación delta (por ejemplo, coordenadas en donde un punto puede codificarse como delta relativo al punto previo en un orden y deltas pueden representarse en menos bytes que la coordenada absoluta). Otros ejemplos pueden incluir compresión de inter-orden, que típicamente se utiliza para codificar una estructura de cierto tipo basándose en una estructura previamente codificada del mismo tipo. Por supuesto, como se reconocerá, los metadatos 140 pueden utilizarse para describir cualquier número de varios comandos de presentación 160 y recursos 165, tal como numerosos módulos de compresión 175 pueden elegirse apropiadamente por el módulo de decisión de codificación 150 como se necesite. Por consiguiente, el uso anterior de tipos particulares de datos para codificación, o cualquier tipo particular de codificación aquí descrito, es para propósitos ilustrativos y no significa que límite o de otra forma estreche las modalidades aquí. Se debe notar que aunque los metadatos 140 se muestran en la tabla de codificación 135 separada del grupo de gráficos 155, otras modalidades también contemplan los metadatos 140 como parte del grupo de gráficos 155. Además, se nota que las distribuciones de varios módulos como se describe aquí pueden combinarse y/o separarse en otras configuraciones y/o diseños esquemáticos. Por consiguiente, el diseño esquemático como se muestra en las varias figuras, así como los módulos o componentes aquí descritos, se utiliza para propósitos ilustrativos solamente y no significa que limiten o de otra forma estrechen el alcance de las varias modalidades a menos que se reclame explícitamente. También se debe notar que los metadatos 165 pueden ser información de tiempo de funcionamiento e información de tiempo de recopilación. Por ejemplo, un Lenguaje de Marcación Extensible (XML) u otro formato binario adecuado) de documento puede incluir metadatos 165 que se intercambian en tiempo de funcionamiento. La diferencia entre los dos es el hecho que la información de tiempo de funcionamiento típicamente se empuja por la máquina de composición 130 a través de una llamada de función específica que permite que el archivo de metadatos (por ejemplo, un documento XML) pase en el módulo de decisión de codificación 150. Típicamente, los metadatos de tiempo de funcionamiento 165 se empujan solamente una vez, en tiempo de inicio. Desde ese punto, la máquina de composición o presentación 130 no tiene que describir completamente el grupo de gráficos 155 al módulo de decisión de codificación 150 cada vez que llama al codificador. En lugar de eso, la máquina de composición 130 simplemente tiene un prefijo (o identificar) cada orden (es decir, comando de presentación y/o recurso) en la corriente con el tipo bien definido en el intercambio de metadatos inicial 165. Los ejemplos posteriores pueden ayudar. Por ejemplo, al asumir que los metadatos 165 se intercambian en tiempo de funcionamiento, los metadatos 165 pueden verse como el siguiente archivo de XML. <GFXMETADATOS> <ORDENARMETADATOS TIPO = "1> <TIPO DE CAMPO = "FLOTAR'7> <TIPO DE CAMP0 = "FL0TAR7> </ORDENARMETADATOS> <ORD EN ARMETA DATOS TIPO> TIPO DE CAMPO = " ENTERO FIRMADO" MIN_VAL = "-255" MAX VAL = "255"/> TIPO DE CAMPO = " ENTERO NOFIRMADO" MIN_VAL = "-4096"MAX_VAL = "40967> < O R D E N > <TIPO DE CAMPO = " COORDENADA" MIN_VAL = "0" MAX_VAL = "65535'7> </ORDEN> </ORDENARMETADATOS> </GFXMETADATOS> <TIPO DE 0RDEN = "1 > <VAL>12.8</VAL> <VAL>21.1 </VAL> </ORDEN> <TIPO DE ORDEN = "2'7> <VAL>200</VAL> <VAL>3993</VAL> <LONGITUD DE VAL = "3"> <VAL>100</VAL> <VAL>200</VAL> <VAL>300</VAL> </VAL> </ORDEN> Se debe notar que en la estructura GFX META DATOS anterior de declaran dos tipos de orden. El primero es un tipo de orden que incluye dos números de punto de flotación. El segundo es un orden que incluye un entero firmado, un entero no firmado, y un orden de coordenadas. Estos metadatos deben comunicarse al módulo de decisión de codificación 150 en el tiempo de inicio. Después del inicio, la segunda estructura (ORDEN) puede utilizarse para enviar órdenes al segundo codificador 150. Se debe notar como la segunda estructura no describe los tipos, sólo los valores. Incluso en la representación de XML, se puede observar que al dividir los metadatos de la segunda estructura de datos (ORDEN) se necesita menos información para comunicarse al módulo de decisión de codificación 150 el contenido para un orden. Los metadatos 140 son muy estáticos lo que algunas veces se percibe para comunicarse solo una vez. Los datos de orden, por otro lado, son datos dinámicos y típicamente no deben unirse a ninguna información estática al mismo. Tal beneficio es más dramáticamente notable cuando un formato binario (como se describió posteriormente) se utiliza tanto para datos como para metadatos en lugar de XML. El codificador o módulo de decisión de codificación 150 solo puede observar al tipo de orden y se conocerá basado en la descripción de metadatos como codificar los valores. Por ejemplo, otros archivos (por ejemplo, una Definición de Interfase o archivo de Lenguaje de Descripción (IDL)) representan un contrato de tipo de recopilación entre el codificador 175 o el módulo de decisión de codificación 150 y la máquina de composición 130. Si el contrato cambia, los dos componentes se tienen que recopilar al utilizar el archivo común (por ejemplo, IDL). Al utilizar el archivo común asegura que los dispositivos operan en los mismos formatos de estructura de datos binaria sin embargo, se debe notar que describir los datos en tiempo de recopilación probablemente resultará en una operación más rápida del módulo de decisión de codificador 150 (como se describió anteriormente) ya que el mismo código de codificación se generará directamente de la descripción de datos de gráficos. Sin embargo, la descripción de tiempo de recopilación vastamente depende en el lenguaje utilizado. Por ejemplo, en un C y C + + puede utilizarse un grupo de macros para definir los primitivos de gráficos. Al utilizar macros uno puede definir tanto la estructura de formato de máquina como la codificación o el mismo código de red. Una vez que se codificó la compresión de datos apropiada 175 uno o más campos dentro del grupo de gráficos 155, estos campos (o grupo de gráficos 155) se envia al dispositivo remoto 110 en donde se comprimen al utilizar el módulo 180 y regenerarse, como se muestran en el grupo de gráficos 190. Como tal la máquina de composición 195 puede utilizar estos para generar una estructura de datos de presentación 185 que está en sincronización con la estructura de datos de presentación 178 en el dispositivo local 105. Además, esta estructura de datos de presentación 185 entonces puede componerse para que el controlador de presentación 104 pueda generar la presentación apropiada 102 que representa las presentaciones de las aplicaciones 115 del dispositivo local 105. Por consiguiente, mientras el usuario en el dispositivo remoto 110 interactúa con la presentación 102 diferentes grupos de gráficos 155 pueden generarse y se codifica como se describió previamente para sincronizar las estructuras de datos de presentación 178, 185. En otra modalidad ilustrativa, el tipo de codificación de módulo de compresión de datos 175 elegido puede basarse en esos tipos de codificación soportados en el dispositivo remoto 110. Por ejemplo, durante un inicio de la conexión (o en algún otro tiempo después de eso), la compresión de datos de tipos puede negociarse entre el dispositivo local y el dispositivo remoto 110. Por consiguiente, como se muestra, el dispositivo remoto 110 envía tipos de codificación soportados 184, que entonces pueden incluirse en una lista de mecanismos de codificación disponibles 145. Esta lista de mecanismos de codificación disponibles 145 entonces puede utilizarse por el módulo de decisión de codificación 150 al elegir el módulo de compresión de datos apropiados 175 para comprimir campos dentro del grupo de gráficos 155 como se descri ió previamente. Se debe notar que aunque se negocian los mecanismos de codificación disponible 145 entre el dispositivo remoto 110 y el dispositivo local 105 típicamente en tiempo de conexión, el mecanismo de compresión exacto utilizado por el dispositivo local 105 para comprimir porciones de un grupo de gráficos 155 se decidirá al momento en el tiempo de la compresión. Por consiguiente, el dispositivo remoto 110 no tendrá conocimiento previo sobre el tipo exacto de compresión de datos 175 que se utilizará. Sin embargo, debido a los tipos de codificación soportado 184 que se determinan antes a mano, el dispositivo local 105 puede asegurarse que el uso de cualquiera de tales tipos de codificación soportados 184 puede controlarse por el dispositivo remoto 110. Además se debe notar que la lista de mecanismos de codificación disponible 145 también puede basarse en aquellos disponibles en el dispositivo local 105 también. En otras palabras, los módulos de compresión de datos 175 y los módulos de descompresión de datos 180 necesitan tener tipos comunes entre ellos. También se debe notar, como se contempla aquí, cualquier tipo bien conocido de mecanismo de codificación puede utilizarse (por ejemplo, RLE, basado en MPEG, JPEG, GIF, ZIP, basado en LZ, JVIG, DejaVu, u otro patrón bien conocido o mecanismo de compresión basado en estadística que son formatos de compresión sin pérdida o con pérdida). También se debe notar que uno o más de los campos dentro de un grupo de gráficos 155 puede codificase al utilizar una relación jerárquica de la codificación u otros módulos de compresión de datos 175 con el fin de comprimir muy eficientemente los datos para enviarse sobre la red al dispositivo remoto 110. La Figura 1B ilustra un sistema de distribución similar como se describió previamente tanto con un dispositivo local 105 como con uno remoto 110. Se debe notar que la Figura 1 B es una versión simplificada del sistema previamente mencionado; y por lo tanto se muestra con componentes faltantes o módulos para simplificar el diagrama esquemático. En las modalidades descritas aquí, sin embargo, en lugar de determinar que tipos de codificación deben utilizarse para los grupos de gráficos de codificación 155, se utilizan varios mecanismos para elegir recursos (si hay algunos) para enviar al dispositivo remoto 110. En tal modalidad, se proporciona el guardado en memoria caché de recurso de aplicación se proporciona en donde los recursos heterogéneos se tratarán en una forma homogénea cuando viene para almacenarlos. Por ejemplo, una primera aplicación (por ejemplo, Aplicación 1) 115 puede hacer una llamada para recurso "A" 106. Mientras los recursos se envían a través de la red para el dispositivo remoto 110, el estado de entrega de tales recursos puede almacenarse en la tabla de recursos 112 (que en este caso muestra el estado de entrega de recurso "A" 114 como ya transferidos). En el dispositivo remoto 110, el recurso "A" 106 se almacenará en una memoria caché central 128 como se muestra en la lista de recursos 118 aquí. Por consiguiente, la siguiente vez que la aplicación 115 desee utilizar el recurso "A" 106, en lugar de enviar al recurso al dispositivo remoto 110, el administrador de recurso 108 identificará el recurso como ya enviado, y simplemente proporcionará un comando de presentación 160 con la ID de recurso 161 para enviar al dispositivo remoto 110. En otras palabras, el recurso (en este caso recurso "A" 106) solo necesita enviarse una vez a través de la conexión entre los dispositivos locales 105 y remotos 110 y puede utilizarse repetidamente a través de varias aplicaciones diferentes (por ejemplo, aplicación 2 que también llama al recurso "A" 106).

Se debe notar que aunque algunos mecanismos de guardar en memoria caché utilizados por ciertos protocolos (por ejemplo, RDP) permiten guardar en memoria caché los recursos, tales memorias caché típicamente se separan basándose en los tipos de recurso utilizados (por ejemplo, grabados, mapas de bits, objetos móviles, etc.)- Aunque tales mecanismos pueden ser tan eficientes como el mecanismo de guardado en memoria caché central más genérico aquí proporcionado, estos acercamientos son no extensibles. Al proporcionar una memoria caché central 128 para almacenar tales recursos 180, la presente invención extiende la capacidad de utilizar tales recursos 106 a través de varias aplicaciones 115 y a través de diferentes estructuras de datos de presentación 178, 185 que pueden utilizarse. Por ejemplo, un mecanismo de guardado en memoria caché genérico aquí proporcionado (que utiliza, por ejemplo, RDP) tiene el beneficio agregado de un recurso que se envía solo una vez y se utiliza por múltiples nodos en una estructura o árbol de composición. Por ejemplo si se utiliza un icono por múltiples aplicaciones 115, ese icono estará presente en cada uno de los sub-árboles de composición (o estructuras de datos de presentación 178, 185) que corresponde a esas aplicaciones 115. Sin tal mecanismo de guardado en memoria caché, el recurso necesitará enviarse al dispositivo remoto 110 para cada nodo que lo utiliza. Con el mecanismo de almacenamiento central proporcionado aquí, sin embargo, un recurso 165 se envía solamente una vez la primera vez que se agrega al recurso 165 a un nodo y se utiliza por múltiples modos en una estructura de datos de composición. También se debe notar que el dispositivo local 105 y el dispositivo remoto 110 puede o no utilizar mecanismos que limitan la fragmentación de memoria causada por recursos de guardado en memoria caché con tamaños vastamente diferentes. Además, se debe notar que debido a que el acercamiento no extensible aún puede proporcionar un mecanismo eficiente para acceder a recursos, tal acercamiento puede utilizarse en conjunto con el guardado en memoria caché genérico aquí proporcionado. Incluso en otra modalidad ilustrativa, se proporciona un mecanismo para proporcionar respuesta al presentarse con recursos parcialmente enviados. En tal caso, la limitación de sistema 116 tal como ancho de banda, o limitaciones de presentación en el dispositivo remoto 110 pueden identificarse por el módulo de decisión de codificación 150 que incluye administrador de recurso 108. Basándose en tales limitaciones de sistema 116, el administrador de recurso 108 puede determinar solo que los recursos parciales 163 deben estar presentes en los comandos de presentación 160 para el grupo de gráficos 155 como se describió previamente. Más específicamente, típicamente existen dos piezas de información necesarias para presentar un grupo de gráficos 155. La primera parte, aquí mostrada como comandos de presentación 160, describe las operaciones de presentación reales para un recurso 165. Típicamente, contienen instrucciones sobre cómo y qué recurso 165 debe utilizarse para presentación. La segunda parte, representa el recurso 168 utilizado para presentación. Como se puede observar, presentar o exhibir comandos 160 típicamente es necesario para enviarse por completo al cliente o dispositivo remoto 110 antes que se pueda comenzar la presentación. Esto, sin embargo, no es el caso con recursos 165. Un recurso 165 no siempre tiene el 100% disponible cuando inicia la presentación para algo significativo que debe presentarse por una aplicación 115. Por ejemplo, un recurso de mapa de bits inicial 165 puede contener una imagen comprimida con una técnica progresiva. Por ejemplo, el color de imagen puede ser inicialmente inexacto para varias limitaciones de anchura de banda u otras consideraciones. Sin embargo, el dispositivo remoto puede utilizar esta borrosidad, sin color, o de otra forma imagen degradada para presentarse en el dispositivo remoto. Por ejemplo tomar el caso en donde el recurso 165 puede ser un botón, mientras el color puede ser vastamente inexacto o puede observarse alguna otra degradación, la representación del botón puede ser lo suficiente para permitir que un usuario ¡nteractúe con el botón sin advertir una versión final del mismo. Sin embargo, mientras más datos de la imagen llegan de la red, el dispositivo remoto 110 puede actualizar la imagen o presentar la estructura de datos 185. Por consiguiente, la respuesta percibida por usuarios dramáticamente aumenta en el caso que la mayoría de los usuarios puede utilizar la aplicación sin todos los recursos 165 presentes. Se debe notar que el ejemplo utiliza una técnica de degradación de color, pero puede utilizarse cualquier clase de codificación o mecanismo de entrelazamiento progresivo igualmente. También se debe notar que este mecanismo de presentación parcial puede trabajar bien para retener sistemas de modo, pero puede no trabajar también para otros modelos (por ejemplo, GDI). La razón es que en el modo retenido una vez que la estructura de datos de presentación 185 (por ejemplo, árbol de composición) se actualiza con el recurso mejorado 165, toda la información está en el lado remoto 110 para activación o retiro. En otros modelos no retenidos (por ejemplo, en modelo GDI), sin embargo, puede no haber mecanismos para recomponer en el remoto 110 lateral, como en el caso en donde ocurre dibujo con un recurso inexacto típicamente no hay mecanismos para renovar el dibujo hasta que el local 105 ó servidor lateral utiliza ese recurso 165 de nuevo en una operación de dibujo. Sin embargo, incluso en el modelo de no retención, puede haber casos en donde es preferible presentar al utiliza recursos inexactos 165 que esperar al recurso completo 165 antes de presentar algo. La Figura 1D ilustra la modalidad anterior que utiliza un orden de coordenadas presentado en una curva 142. Como se muestra, el grupo de recurso completo 144 incluye numerosos puntos a lo largo de la curva 142. Las modalidades, sin embargo, pueden utilizar limitación de sistema 116, para decidir que solo debe enviarse un grupo de recurso parcial 148. Por ejemplo, solo una fracción de los puntos a lo largo de la curva 146 se envía en este ejemplo que mientras no representan la curva exactamente 142 aún permite una ilustración razonable de la imagen total. En otras palabras, la curva exacta 142 se aproxima desde una multitud de puntos, cada punto que representa una muestra digital para esa curva, en donde más de muestras que están presentes, más exacta se verá la curva. Dependiendo de la curva 142, sin embargo, una representación suficientemente cerca 146 puede presentarse al utilizar solo una fracción del número de muestras. El resto de los puntos puede actualizarse en un momento posterior. Mientras llegan las actualizaciones del dispositivo local 105, el dispositivo remoto 110 actualizará el grupo de puntos para esa curva 142 y volverá a presentar la estructura de datos 185 que lo utiliza. Con cada actualización, la curva de presentación 146 se acercará más y más a la forma pretendida final 142. Se debe notar que aunque el ejemplo anterior utiliza una curva o malla gráfica y un botón simple, también pueden utilizar recursos más sofisticados 165 a esta característica. Por ejemplo, una imagen en la forma final como un objeto 3-D puede presentarse inicialmente en forma parcial como un objeto 2-D. Mientras un ancho de banda se vuelve disponible, pueden enviarse más y más información para actualizar la imagen a su forma 3-D final. Por supuesto, como se reconocerá, existen muchos de varios recursos 165 y mecanismos (es decir, como y que porciones de un recurso enviar) que pueden utilizar esta característica. Por consiguiente, los ejemplos anteriores se utilizan aquí para propósitos ilustrativos solamente y no significa que limiten el alcance de estas y otras modalidades. Incluso en otra modalidad ilustrativa, el administrador de recursos 108 puede determinar o identificar esos recursos que se dedican tanto en el dispositivo local 105 como en el dispositivo remoto 110. Por consiguiente, la información de aplicación soportada 122 puede transferirse al dispositivo local 105 con el inicio de la conexión (o en algún momento después de eso). Esta información típicamente incluirá recursos de aplicación 124 soportados y almacenados en el almacenamiento de recurso 126 en el dispositivo remoto 110. Esta información de aplicación soportada 122 entonces puede utilizarse por el administrador de recurso 108 al determinar qué tipos de recursos deben enviarse al dispositivo remoto 110. Por ejemplo, tanto el dispositivo remoto 110 como el local 105 puede tener una aplicación específica (por ejemplo, un tipo específico de editor de texto) instalado. Por consiguiente, los iconos u otros recursos de aplicación 124 asociados con esto también se localizarán en ambos dispositivos 105, 110. En estos casos, el dispositivo local 105 simplemente puede utilizar el comando de presentación 160 e ID de recurso 161 para instruir al dispositivo remoto 110 para utilizar los iconos apropiados, sin el dispositivo local 105 que actúa al tener que enviar el recurso 125 para este. Sin embargo, se debe notar que tal modelo asume de los recursos 124 se almacenan en forma serializada. Pueden transformarse como sea necesario, pero la transformación típicamente toma lugar en la capa de hardware. Por consiguiente, para protocolos o lenguajes gráficos que no transforman el recurso, es posible para el dispositivo local 105 comunicar al cliente las IDs de recurso bien conocidas 161 en lugar de enviar los datos para los recursos 124 a través del cable. Tal uso de recursos de aplicación dedicados 124 en el dispositivo remoto 110 es particularmente ventajoso en el caso en donde los tamaños del recurso 124 son grandes. También se debe notar que el recurso exacto 124 no necesita recibir en dispositivos locales 105 y remotos 110. Por ejemplo, algunas aplicaciones 115 tienen recursos 124 que son comunes entre varias aplicaciones 115. Por ejemplo, la mayoría de las aplicaciones 115 tienen comandos más amplios, barra de título, y de ventana para minimizar/maximizar, pantalla completa/parcial, y/o cerrar iconos. Como tal, los recursos de aplicación 124 utilizados en el dispositivo remoto 110 no necesariamente necesitan corresponder a una aplicación exacta 115 en la máquina local 105, aunque típicamente será el caso que lo hagan. La Figura 1C muestra el uso de varios recursos que pueden utilizarse o que pueden dedicarse tanto en el dispositivo local 105 como en el dispositivo no remoto 110. En este ejemplo, el recurso de borde 132 puede utilizarse para delinear la ventana de presentación de aplicación. Además, la barra de título 135 así como los iconos de manipulación de ventana 136 también pueden ser recursos de aplicación 124 que pueden accederse y utilizarse en el dispositivo remoto 110. Similarmente, una barra de herramientas 138 con varios componentes o iconos también puede utilizarse. Sin embargo, la información que se manipula o de otra forma cambia en el dispositivo local 105 necesitará enviarse a través del cable por modalidades previamente descritas. Incluso en otra modalidad ilustrativa, la codificación anterior y los mecanismos de selección de recurso pueden implementarse como parte de un componente individual. La interfase (o contrato) entre este componente y la aplicación o máquina de composición puede definirse por un lenguaje de definición de interfase como IDL o XML. Sin embargo, el contrato es para proporcionar el módulo de decisión de codificación 150 tanto con datos 165 de recurso como con los metadatos 140 necesarios para codificación eficiente del recurso 165. De esta forma, un cambio en el diseño de recurso 165 u organización no requerida una actualización al módulo de decisión de codificación 150. Solo una actualización a los metadatos 140 se requerirá, que puede realizarse al cambiar la interfase o contrato. La presente invención también puede describirse en términos de métodos que comprenden pasos funcionales y/o actos no funcionales. La siguiente es una descripción de pasos y/o actos que pueden realizarse al practicar la presente invención. Usualmente, los pasos funcionales describen la invención en términos de resultados que se realizan, mientras actos no funcionales describen acciones más específicas para lograr un resultado particular. Aunque los pasos funcionales y/o actos no funcionales pueden describirse o reclamarse en un orden particular, la presente invención no necesariamente se limita a ningún orden particular o combinación de pasos y/o actos. Además, el uso de pasos y/o actos en la recitación de las reivindicaciones (solamente) se utiliza para indicar el uso específico deseado de tales términos. Como se mencionó previamente, las Figuras 2-4 ilustran diagramas de flujo para varias modalidades ilustrativas de la presente invención. La siguiente descripción de las Figuras 1-4 ocasionalmente se referirá a elementos correspondientes de las Figuras 1A-D. Aunque se hace referencia un elemento especifico para estas figuras, tales referencias se utilizan para propósitos ilustrativos solamente y no significa que limiten o de otra forma estrechen el alcance de las modalidades descritas a menos que se reclame explícitamente. La Figura 2 ilustra un diagrama de flujo para un método 200 de codificar eficientemente objetos de gráficos para presentación en un dispositivo remoto para aplicaciones que corren en un dispositivo local al determinar un mecanismo de codificación apropiado sin importar el tipo de lenguaje gráfico utilizado. El método 200 incluye un acto de ejecutar 205 aplicación(es) en un dispositivo local. Por ejemplo, las aplicaciones 115 pueden ejecutarse en el dispositivo local 105, en donde las aplicaciones 115 generan una presentación de gráficos basándose en un lenguaje de gráficos particular, para presentación en un dispositivo remoto 110. Tal lenguaje de gráficos puede incluir GDI, WPF, u otros tipos de lenguajes gráficos actualmente conocidos o futuros. El método 200 también incluye un acto de recibir 210 un grupo de gráficos para un lenguaje de gráficos particular. Por ejemplo, el módulo de decisión de codificación 150 puede recibir grupo de gráficos 155 para un lenguaje de gráficos particular, en donde el grupo de gráficos 155 incluye comando(s) de presentación 160 y/o recurso(s) 165. Tal grupo de gráficos 155 se utilizará para presentar al menos una porción de la presentación de gráficos para las aplicaciones 115 en un dispositivo remoto 110. Se debe notar que estos comandos de presentación pueden incluir propiedades que describen un recurso en términos de posición en una presentación, tamaño, color, forma, etc. Además se debe notar, que los recursos pueden ser cualquiera de los recursos bien conocidos tal como grabados, iconos, objetos móviles, mapas de bits, o cualquier otra imagen. Además, el método 200 incluye un acto de recibir 220 datos de codificación para: (1) metadatos que describen contenidos del grupo de gráficos; (2) codificar datos de tipo que describen mecanismos de compresión de datos soportados por el dispositivo remoto. Por ejemplo, el módulo de decisión de codificación 150 puede recibir los metadatos de grupo de gráficos 140 que describe contenidos de campos dentro del grupo de gráficos 155 utilizados para ayudar a los módulos de compresión de datos 175 a comprimir más eficientemente el grupo de gráficos 155 entonces cuando el grupo de gráficos 155 está en forma normal. Se debe notar que está forma normal puede ser una forma en serie o no en serie. Alternativamente, o en conjunto, el módulo de decisión de codificación 150 puede recibir una lista de mecanismos de codificación disponibles 145 soportados por el dispositivo remoto 110. Estos datos de tipo de codificación describirán los mecanismos de compresión de datos soportados por el dispositivo remoto 110 para seleccionar un tipo de compresión eficiente para el grupo de gráficos 155 como se describió previamente. Basándose en los datos de codificación recibidos, el método 200 también incluye un acto de determinar 225 un mecanismo de codificación apropiado para porciones del grupo de gráficos. Por ejemplo, basándose en los metadatos 140 y la lista de mecanismos de codificación disponibles 145, el módulo de decisión de codificación 150 puede determinar que módulos de compresión de datos 175 codificarán más eficientemente varias porciones del grupo de gráficos 155. La Figura 3 ilustra un método 300 para presentar eficientemente objetos de gráficos en un dispositivo de presentación remota para aplicaciones que corren en un dispositivo local al determinar que (si hay alguno) recursos para la aplicación deben enviarse al dispositivo remoto. El método 300 incluye un acto de ejecutar 305 aplicación(es) en un dispositivo local. Por ejemplo, las aplicaciones 115 pueden ejecutarse en el dispositivo local 105, cada uno de los cuales genera presentaciones gráficas para transmitir al dispositivo remoto 110. El método 300 también incluye un acto de recibir 310 un grupo de gráficos que incluye comando(s) de presentación y/o recurso(s). Por ejemplo, el módulo de decisión de codificación 150, en conjunto con el administrador de recurso 108, puede recibir un grupo de gráficos 155 que incluye recursos 165 y/o comandos de presentación 160, que se van a utilizar al presentar al menos una porción de las presentaciones de gráfico para las aplicaciones 115 en el dispositivo remoto 110. El método 300 también incluye un acto de recibir 315 datos de recurso para: (1) información de estado de entrega; (2) información de aplicación soportada; (3) datos de limitación de sistema; y/o (4) información de visibilidad. Más específicamente, el administrador de recursos 108 puede recibir datos de recurso para determinar el estado de entrega de un recurso 165. Por ejemplo, la tabla de estado de recurso 112 puede utilizarse por el administrador de recurso 108 para determinar el estado de entrega de recurso, que corresponde al grupo de gráficos 155, con el fin de determinar si el recurso correspondiente (por ejemplo, recurso A 114) se envió al dispositivo remoto 110 y se almacenó en la memoria caché central 128 para propósitos de reutilización sin considerar el tipo de recurso almacenado. En otras palabras, los recursos de varios tipos se almacenan dentro de la memoria cache central 128 para que los recursos heterogéneos se traten en una forma homogénea cuando los almacena. Se debe notar que el dispositivo local 105 y el dispositivo remotos 110 puede o no utilizar mecanismos que limitan la fragmentación de memoria causada por recursos guardados en memoria cache con tamaños vastamente diferentes. Además, el módulo de división de codificación 150 ó administrador de recurso 108 puede recibir información de aplicación soportada 122 para determinar recursos dedicados 124 actualmente disponibles en el dispositivo remoto 110 con el fin de presentar tal recurso sin transferir el recurso del dispositivo local 105. En otras palabras, tanto en el dispositivo remoto 110 como en el dispositivo local 105 tienen una aplicación similar o igual instalada, recursos o iconos pueden identificarse y se dedican en el dispositivo remoto 110 y presentarse tal como aquellos recursos que no se enviaron del dispositivo local 105 al dispositivo remoto. Tales recursos dedicados pueden incluir un borde, una barra de título, una barra de herramientas, o alguna otra forma de icono o recurso estándar a través de ambas aplicaciones. Además, el módulo de decisión de codificación 150 ó administrador de recurso 108 también puede recibir información de limitación de sistema 116 para determinar si las porciones de un recurso deben enviarse progresivamente al dispositivo remoto 110, tal como una versión degradada de recurso completo que se envía primero y actualizaciones que mejoran la versión degradada que son subsecuentemente enviadas para guardar ancho de banda u otras limitaciones de sistema. Por ejemplo, como se muestra en la Figura 1D, en el grupo de recursos completos 144 que muestra una curva 142 con un alto muestreo puede enviarse primero como un grupo de recurso parcial 148 que solo incluye una fracción del grupo de muestreo total como se muestra a partir de la curva 146. Se debe notar que los recursos parciales que se envían progresivamente al dispositivo remoto pueden incluir mapas de bits, curvas, mallas, u otras formas de imagen. También se debe notar que la versión degradada incluye imprecisiones de color, detalle, número de puntos de muestra, u otra degradación de calidad de imagen, pero la versión degradada del recurso debe incluir suficiente información para permitir que un usuario en el dispositivo remoto 110 reconozca el recurso. Además se debe notar que el recurso puede ser un botón, cuadro de revisión, u otro artículo interactivo, y el usuario aún debe ser capaz de interactuar con el artículo sin recibir el recurso completo. Además, el módulo de decisión de codificación 150 ó administrador de recurso 108 puede recibir información de visibilidad 113 de una tabla de estado de recurso 112 que describe si o no uno o más recursos 165, que corresponden al grupo de gráficos 155, puede observarse actualmente por un usuario. Tal información de visibilidad puede incluir información sobre un Orden Z, transparencia, estado de minimizar/maximizar del recurso, etc. Por consiguiente, los recursos que pueden no ser visibles pueden retrasarse al enviar al dispositivo remoto 110 hasta que el ancho de banda permite o hasta que se necesite para observación. Basándose en la información de recurso recibida, el método 300 incluye un acto de seleccionar 320 porciones del grupo de gráficos para codificación. En otras palabras, basándose en el estado de entrega anterior, la información de aplicación soportada, datos de limitación de sistema, y/o información de visibilidad, porciones del grupo de gráficos 155 (es decir, campos del comando de presentación o porciones de los recursos) se seleccionarán para codificación al utilizar módulos de compresión de datos 175. La Figura 4 ilustra un método 400 de sincronizar eficientemente estructuras de datos de presentación utilizadas al generar una presentación de gráficos en un dispositivo remoto para aplicaciones ejecutadas en un dispositivo local. El método 400 incluye un acto de ejecutar 405 aplicación(es) en un dispositivo local. Por ejemplo, como se describió previamente, las aplicaciones 115 pueden ejecutarse en el dispositivo local 105, cada una de las cuales genera estructuras de datos de presentación 178 de un lenguaje de gráficos particular, que retienen estructuras de datos de modo que mantienen estado para recurso 165 y se utilizan para componer una presentación de gráficos para aplicaciones 115 en el dispositivo remoto 110. El método 400 también incluye un acto de recibir 410 un grupo de gráficos que incluye recurso(s) y/o, comando(s) de presentación. Por ejemplo, el módulo de decisión de codificación 150 puede recibir grupo de gráficos 155 que incluye comandos de presentación 160 y/o recursos 165. Los comandos de presentación 160 pueden incluir propiedades que escriben un recurso 165 en términos de colocación en una presentación, tamaño, color, forma, etc. El método 400 también incluye un acto de recibir 114 metadatos que incluyen una descripción de grupo de gráficos. Por ejemplo, el módulo de decisión de codificación 150 puede recibir los metadatos de grupo de gráficos 140 que incluye una descripción de campos del grupo de gráficos 155 con el fin de ayudar a los módulos de compresión 175 a identificar un tipo de estructura para el campo común entre la pluralidad del grupo de gráficos 155 para diferentes lenguajes de gráficos que el módulo de compresión de datos 175 puede reconocer más fácilmente y codificar apropiadamente. Por ejemplo, basándose en los metadatos 140, los campos pueden convertirse de formato de máquina a forma de red, que reduce la longitud de bit de los campos para mejor relación de compresión entonces cuando este en forma de máquina. Además, los metadatos 140 pueden utilizarse para codificación en forma de longitud variable o para codificación delta utilizada solo cuando se envía un cambio en el recurso al dispositivo remoto, que puede codificarse al utilizar menos bytes que al enviar el grupo de gráficos completo 155. Además, los metadatos 140 pueden utilizarse para un mecanismo de compresión de inter-orden utilizado para codificar los campos de cierto tipo basándose en estructura previamente codificada del mismo tipo. Se debe notar que los metadatos 140 pueden o no unirse al grupo de gráficos 155. Por ejemplo, típicamente el intercambio de metadatos 155 es un evento a tiempo que describe los tipos de grupo de gráficos 155 (por ejemplo, ordenes/comandos o recursos) utilizados. Entonces cada grupo de gráficos 155 puede precisarse con el tipo (o identif icador) . El módulo de decisión de codificación 150 entonces es capaz de ver ese identificador y elegir el módulo de compresión de datos apropiados 175, el orden de codificación apropiado, etc., basándose en los metadatos inicialmente intercambiados 155. Basándose en los metadatos recibidos, el método 400 incluye un acto de codificar 420 campos del grupo de gráficos. Por ejemplo, el módulo de decisión de codificación 150 basándose en los metadatos de grupo de gráficos 140 que describe los campos dentro del grupo de gráficos 155 puede utilizar tales datos para codificar campos para enviar al dispositivo remoto 105 y sincronizar estructuras de datos de presentación 178, 185 entre los dispositivos locales 105 y remotos 110, que se utilizan para componer una presentación de gráficos en el dispositivo remotos 110 para las aplicaciones 1 5. La presente invención puede ser modalizada en otras formas específicas sin apartarse de su espíritu o características esenciales. Las modalidades descritas se deben considerar en todos los aspectos solo como ilustrativas y no restrictivas. El alcance de la invención, por lo tanto, se indica por las reivindicaciones anexas en lugar de por la descripción anterior. Todos los cambios que vienen dentro del significado y alcance de equivalencia de las reivindicaciones se van a abarcar dentro de su alcance.

Claims (2)

REIVINDICACIONES

1 - En un sistema de cómputo distribuido, un método para codificar eficientemente objetos de gráfico para presentación en un dispositivo remoto para una o más aplicaciones que corren en un dispositivo local al determinar un mecanismo de codificación apropiado sin importar el tipo de lenguaje de gráficos utilizado, el método comprende: ejecutar una o más aplicaciones en un dispositivo local, cada uno de los cuales genera una presentación de gráficos, basándose en un lenguaje de gráficos particular, para presentación en un dispositivo remoto; recibir un grupo de gráficos para lenguaje de gráficos particular, en donde el grupo de gráficos incluye uno o más recursos, uno o más comandos de presentación, o ambos, que se utilizan para presentar al menos una porción de la presentación de gráficos para una o más aplicaciones; recibir datos de codificación que incluyen información para uno o más de los siguientes: (1) metadatos que describen los contenidos de uno o más campos dentro del grupo de gráficos utilizado para ayudar a uno o más módulos de compresión de datos a comprimir más eficientemente el grupo de gráficos que cuando el grupo de gráficos está en forma normal; (2) codificar datos de tipo que describen uno o más mecanismos de compresión de datos soportados por el dispositivo remoto para seleccionar un tipo de compresión eficiente para el grupo de gráficos; y basándose en los datos de codificación recibidos, determinar un mecanismo de codificación apropiado para una o más porciones del grupo de gráficos.

2 - El método de acuerdo con la reivindicación 1, en donde uno o más comandos de presentación incluye una o más propiedades que describen un recurso en términos de uno o más de colocar una presentación, tamaño, color, o forma. 3.- El método de acuerdo con la reivindicación 1 , en donde basándose en los metadatos, uno o más de los campos se convierten de formato de máquina a formato de red, lo que reduce la longitud de bit de uno o más campos para mejor relación de compresión que cuando está en forma de máquina. A.- El método de acuerdo con la reivindicación 1, en donde basándose en los metadatos, uno o más de los campos son codificados en forma de longitud variable. 5. - El método de acuerdo con la reivindicación 1, en donde basándose en los metadatos, se utiliza una codificación delta para que solo un cambio en un recurso se envié al dispositivo remoto, el cual puede codificarse utilizando menos bytes que enviar el grupo de gráficos completo. 6. - El método de acuerdo con la reivindicación 1, en donde basándose en los metadatos, se utiliza un mecanismo de compresión de ¡nter-orden para codificar uno o más de los campos de cierto tipo basándose en una estructura previamente codificada del mismo tipo. 7. - El método de acuerdo con la reivindicación 1, en donde uno o más de los mecanismos de compresión de datos soportados por el dispositivo remoto se negocian entre el dispositivo local y remoto en el tiempo de conexión, y en donde el mecanismo de codificación elegido además se basa en qué tan bien cada mecanismo de compresión comprime el grupo de gráficos dado. 8. - El método de acuerdo con la reivindicación 7, en donde uno o más de los módulos de compresión de datos incluye uno o más de RLE, basados en MPEG, JPEG, GIF, ZIP basados en LZ, JVIG, DejaVu, u otro patrón bien conocido o mecanismo de compresión basado en estadística. 9. - En un sistema de cómputo distribuido, un método para presentar eficientemente objetos de gráficos en un dispositivo de presentación remoto para una o más aplicaciones que corren en un dispositivo local al determinar qué recursos (si hay alguno) para una o más aplicaciones deben enviarse al dispositivo remoto, el método comprende: ejecutar una o más aplicaciones en un dispositivo local, cada uno de los cuales genera presentaciones de gráficos para transmitir a un dispositivo remoto; recibir un grupo de gráficos que incluye uno o más recursos, uno o más comandos de presentación, o ambos, que se utilizan al presentar al menos una porción de las presentaciones de gráficos para una o más aplicaciones; recibir datos de recurso que incluyen información para uno o más de los siguientes: (1) información de estado de entrega para determinar si uno o más recursos, que corresponden al grupo de gráficos, se envió al dispositivo remoto y se almacenó en una memoria caché central para propósitos de re uti I izació n con respecto al tipo de recurso almacenado; (2) información de aplicación soportada para determinar recursos dedicados actualmente disponibles en el dispositivo remoto con el fin de presentar al menos un recurso en el dispositivo remoto para una o más aplicaciones sin transferir al menos un recurso desde el dispositivo local; (3) datos de limitación de sistema para determinar si las porciones de un recurso deben enviarse progresivamente al dispositivo remoto para que una versión degradada del recurso completo primero se envíe y las actualizaciones que mejoran la versión degradada son subsecuentemente enviadas para guardar anchura de banda u otras limitaciones de sistema; o (4) información de visibilidad que describe si uno o más recursos que corresponden al grupo de gráficos puede o no verse actualmente por un usuario; y basándose en la información de recurso recibida, seleccionar porciones del grupo de gráficos para codificación. 10.- El método de acuerdo con la reivindicación 9, en donde el dispositivo local, dispositivo remoto, o ambos utilizan mecanismos que limitan fragmentación de memoria causada por guardado en memoria caché de uno o más recursos de diferentes tamaños dentro de la memoria caché central. 11.- El método de acuerdo con la reivindicación 9, en donde los recursos dedicados actualmente disponibles en el dispositivo remoto incluyen uno o más de un borde para una o más aplicaciones, una barra de título para una o más aplicaciones, una barra de herramientas para una o más aplicaciones, o alguna otra forma de estándar de icono a través de una o más aplicaciones. 12.- El método de acuerdo con la reivindicación 9, en donde la información de visibilidad incluye información sobre el Orden Z, transparencia, o estado de minimizar/maximizar de uno o más recursos. 13.- El método de acuerdo con la reivindicación 9, en donde el recurso para la porción del recurso progresivamente enviado al dispositivo remoto incluye uno o más mapas de bits, curvas, o mallas, y en donde la versión degradada incluye inexactitudes de uno o más de color, detalle, número de puntos de muestra, u otra degradación de calidad de imagen, pero la versión degradada del recurso incluye suficiente información para permitir que un usuario en el dispositivo remoto reconozca el recurso. 14. - El método de acuerdo con la reivindicación 13, en donde el recurso es un botón, cuadro de revisión, u otro artículo interactivo, y en donde el usuario es capaz de interactuar con el artículo sin recibir el recurso completo. 15. - En un sistema de cómputo distribuido, un método para sincronizar eficientemente estructuras de datos de presentación utilizadas para generar una presentación de gráficos en un dispositivo remoto para una o más aplicaciones ejecutadas en un dispositivo local, el método comprende: ejecutar una o más aplicaciones en un dispositivo local, cada una de las cuales genera una estructura de datos de presentación de un lenguaje de gráficos particular, que son estructuras de datos de modo de retención que mantienen estado para recursos y se utilizan para componer una presentación de gráficos para una o más aplicaciones en un dispositivo remoto; recibir un grupo de gráficos que incluye uno o más recursos, uno o más comandos de presentación, o ambos, que corresponden al lenguaje de gráficos particular y se utilizan para modificar una o más de las estructuras de datos de presentación; recibir metadatos que incluyen una descripción de uno o más campos del grupo de gráficos con el fin de ayudar a uno o más módulos de compresión de datos a identificar un tipo estructura para uno o más campos comunes entre una pluralidad de grupos de gráficos para uno o más lenguajes de gráficos diferentes que uno o más módulos de compresión de datos puede reconocer más fácilmente y codificar apropiadamente; y basándose en los metadatos recibidos, codificar uno o más campos del grupo de gráficos para enviar al dispositivo remoto y sincronizar estructuras de datos de presentación entre los dispositivos locales y remotos, que se utilizan para componer una presentación de gráficos en el dispositivo remoto para una o más aplicaciones. 16.- El método de acuerdo con la reivindicación 15, en donde uno o más comandos de presentación incluye una o más propiedades que describen un recurso en términos de uno o más de colocar una presentación, tamaño, color, o forma. 17. - El método de acuerdo con la reivindicación 15, en donde basándose en los metadatos, uno o más de los campos se convierten de formato de máquina a formato de red, lo que reduce la longitud de bit de uno o más campos para mejor relación de compresión que cuando está en forma de máquina. 18. - El método de acuerdo con la reivindicación 15, en donde basándose en los metadatos, uno o más de los campos se codifican en forma de longitud variable. 19. - El método de acuerdo con la reivindicación 15, en donde basándose en los metadatos, se utiliza una codificación delta de manera que solo un cambio en un recurso se envía al dispositivo remoto, que puede codificarse al utilizar menos bytes que enviar el grupo de gráficos completo. 20. - El método de acuerdo con la reivindicación 15, en donde basándose en los metadatos, un mecanismo de compresión de inter-orden se utiliza para codificar uno más de los campos de cierto tipo basándose en una estructura previamente codificada del mismo tipo.