MXPA05006641A - Interfases visuales y graficos de escena. - Google Patents

Abstract

Un metodo y sistema implementado en una interfase de programacion de aplicacion (API), y un modelo de objeto permite que los desarrolladores del codigo del programa hagan una interfase de una manera consistente con un estructura de datos de graficos de escena para producir graficos. Por medio de la interfase, el codigo de programa escribe primitivas de dibujos, tales como datos de geometria, datos de imagen de imagen, datos de animacion y otros datos a los visuales que representan una superficie de dibujo, incluyendo objetos visuales de validacion, objetos visuales de dibujo y objetos visuales de superficie. El codigo tambien puede especificar transformaciones, propiedades de transformacion, sujecion y opacidad de los visuales y agregar visuales descendentes a otros visuales para construir una grafica de escena jerarquica. Un administrador visual atraviesa la grafica de escena para proporcionar datos ricos de graficos a los componentes de graficos de nivel mas bajo.

Description

INTE FASES VISUALES Y GRÁFICOS DE ESCENA Campo de la Invención La presente invención se refiere generalmente a sistemas de computadora, y más particularmente al procesamiento de gráficos y otra información de video, para desplegarlos en la pantalla de un sistema de cómputo. Antecedentes de la Invención Los límites del modelo del modo inmediato tradicional para tener acceso a ios gráficos en los sistemas de computadora están siendo alcanzados, debido en parte a que la memoria y que las velocidades de la memoria y el bus no están al corriente con los avances en los procesadores principales y/o los procesadores de gráficos. En general, el modelo actual (es decir, el WM_PAI NT) para preparar un cuadro requiere demasiado procesamiento de datos para continuar con el índice de recordatorio del hardware cuando se desean efectos complejos de los gráficos. Como resultado, cuando se intentan efectos complejos de los gráficos con los modelos de gráficos convencionales, en vez de completar los cambios que son el resultado de los efectos visuales percibidos en el tiempo para el siguiente cuadro, los cambios pueden ser agregados en diferentes cuadros, ocasionando resultados que son indeseables y notorios visualmente. Un modelo nuevo para controlar la producción de gráficos se describe en las Solicitudes de Patente Norteamericana Series Nos. 10/184,795, 10/184,796, 10/185,775, 10/401,717, 10/402,322 y 10/402,268, asignadas al cesionario de la presente invención e incorporadas a la presente descripción como referencia. Este modelo nuevo proporciona un número de mejoras importantes en la tecnología de procesamiento de gráficos. Por ejemplo, la Solicitud de Patente Norteamericana Serie No. 10/184,795 está dirigida generalmente hacia el método y el sistema de procesamiento de gráficos de nivel múltiple, en el cual un componente de nivel más alto, (por ejemplo, de un sistema operativo) realiza aspectos intensos de computación para construir un gráfico de escena, actualizando los parámetros de animación y atravesando las estructuras de datos de los gráficos de escena, en un rango de operación relativamente bajo, con el objeto de pasar las estructuras simplificadas de datos y/o comandos de los gráficos a un componente de bajo nivel. Debido a que el procesamiento de alto nivel simplifica en gran parte los datos, el componente de bajo nivel puede operar en un índice más rápido (en relación con el componente de alto nivel), tal como un índice que corresponde al índice de recordatorio del cuadro del subsistema de gráficos, para procesar los gráficos en datos de salida constantes para el subsistema de gráficos. Cuando se utiliza la animación, en vez de tener que volver a dibujar una escena completa con cambios, el procesamiento de bajo nivel puede interpolar los intervalos de parámetros que sean necesarios para obtener los valores instantáneos, que cuando son presentados, proporcionan una escena ligeramente cambiada para cada cuadro, proporcionando una animación suave. La Solicitud de Patente Norteamericana Serie No. 10/184,796 describe un gráfico de escena parametrizado que proporciona valores mutables (animados) y contenedores de gráficos parametrizados, de modo que el código del programa que quiere dibujar gráficos (por ejemplo, un programa de aplicación o un componente del sistema operativo), puedan cambiar selectivamente ciertos aspectos de la descripción del gráfico de escena, mientras que se dejan intactos otros aspectos. El código del programa también puede volver a usar porciones ya construidas del gráfico de escena, posiblemente con diferentes parámetros. Como se puede apreciar, la capacidad para cambiar fácilmente la apariencia de las partidas desplegadas en pantalla por medio de la parametrización y/o el nuevo uso de las partes existentes de los gráficos de escena, proporciona ganancias substanciales en la eficiencia general de procesamiento de gráficos. La Solicitud de Patente Norteamericana Serie No. 10/185,775 describe generalmente una estructura de datos para almacenarlos en la memoria temporal y mecanismos relacionados para almacenar la información visual por medio de objetos y datos en uno gráfico de escena. La estructura de datos está generalmente asociada con los mecanismos que controlan de manera inteligente la forma en que la información visual en la misma es llenada y utilizada. Por ejemplo, a menos que se solicite específicamente por el programa de aplicación, la mayor parte de la información almacenada en la estructura de datos no tiene referencia externa a la misma, lo cual hace posible que esta información sea optimizada o procesada de otro modo. Como se puede apreciar, esto proporciona eficiencia y la conservación de recursos, es decir, los datos en la estructura de datos de la memoria temporal pueden ser procesados en un formato diferente que es más compacto y/o reduce la necesidad de un procesamiento posterior repetido, tal como un mapa de bits u otros resultados de procesamiento posterior. Aunque las mejoras anteriores proporcionan beneficios substanciales en fa tecnología de procesamiento de gráficos, todavía es necesario que exista un medio para que los programas utilicen de manera efectiva estos modelos de gráficos mejorados y sus otras mejoras relacionadas de una manera directa. Los que se necesita es un modelo extenso y todavía directo para que los programas aprovechen muchas características y capacidades de los procesamientos de gráficos proporcionados por el modelo mejorado de gráficos y por lo tanto, produzcan gráficos complejos y datos audiovisuales de una manera eficiente. Sumario de la Invención Brevemente, la presente invención proporciona un modelo de objeto, y una interfase de programación de aplicación (API) para tener acceso a ese modelo de objeto de una manera que permita que los desabolladores de código del programa hagan interfase de manera consistente con una estructura de datos de gráficos de escena para producir gráficos. Un objeto básico en el modelo y el conjunto API es un visual, el cual representa una superficie virtual para el usuario; el gráfico de escena es construido de objetos visuales. Dichos visuales incluyen objetos visuales del contenedor, objetos visuales retenidos, objetos visuales de dibujo y otros objetos visuales. Los visuales por ellos mismos pueden conservarse en los objetos fuente, tales como objetos de sujeción, transformar objetos, y así sucesivamente, y algunos tipos de visuales (por ejemplo, DrawingVisual, RetainedVisual) pueden mantenerse en las listas de instrucción de dibujo que pueden ser objetos de recurso de referencia, tales como imágenes, pinceles y/o gradientes. En el gráfico de escena la mayor parte de objetos de recursos son inmutables una vez que son creados, es decir, una vez que son creados no pueden ser cambiados. Para esos objetos que un desarrollador quiere cambiar fácilmente, se proporciona la mutabilidad por un patrón de cambiables e implementación, tal y como se describieron en la Solicitud de Patente Norteamericana titulada "Clase Cambiable y Patrón para Proporcionar la Mutabilidad Selectiva en Entornos de Programación de Cómputo" presentada junto con la presente, asignada al cesionario de la presente invención e incorporado a la presente descripción como referencia. Por medio de las interfases de programación de aplicación, el código del programa escribe las primitivas de dibujo, tales como los datos de geometría, datos de imagen, datos de animación y otros datos para los visuales. Por ejemplo, el código del programa escribe en los visuales primitivas de dibujo tales como instrucciones de líneas de dibujo, instrucciones de geometría del dibujo, instrucciones de mapa de bits del dibujo y así sucesivamente. Esas instrucciones de dibujo, con frecuencia son combinadas con datos complejos, como datos de geometría que describen la forma en que se dibuja una trayectoria, y también pueden ser recursos de referencia como mapas de bits, videos y así sucesivamente. El código también puede especificar la sujeción, opacidad y otras propiedades de los visuales, y los métodos para impulsar y hacer surgir la transformación, proporcionan la opacidad y la identificación de la prueba de recuperación. Además, el visual puede participar en la prueba de recuperación. El código del programa también hace interfase con los visuales para agregar visuales descendientes, acumulando de este modo, una gráfica de escena jerárquica. Un administrador visual procesa (es decir, atraviesa o transmite), el gráfico de escena para proporcionar datos de gráficos ricos a los componentes de gráficos del nivel más bajo. Los visuales del contenedor proporcionan una colección de visuales descendientes y en una implementación, son los únicos visuales que pueden definir la jerarquía. La colección de descendientes en un visual del contenedor permite la inserción arbitraria, la remoción y el reordenamiento de los visuales descendientes. Los visuales de dibujo se abren con una invocación de abrir que regresa un contexto de dibujo (por ejemplo, una referencia o un objeto de contexto de dibujo) para el invocador. En general, un contexto de dibujo es un objeto de ayuda temporal que es utilizado para llenar un visual. El código del programa entonces utiliza al contexto de dibujo para agregar primitivos de dibujo ai visual. La invocación de abrir puede despejar el contenido (descendientes) de un visual, o una invocación de adjuntar puede ser utilizada para abrir un visual para adjuntarlo al visual actual. Además de recibir valores estáticos como parámetros de dibujo, los contextos de dibujos pueden ser llenados con objetos de animación. Un visual retenido opera de una manera similar a un visual de dibujo, excepto que su contexto de dibujo es llenado cuando el sistema solicita que sea llenado, en vez de que cuando el código de programa quiera que se llene. Por ejemplo, si un contenido de un visual particular se necesita en la presentación de una escena, el sistema invocará IRetainedVisual.Render para llenar el contenido del visual, reemplazando cualquier contenido que ya se encuentre en la memoria. Por lo tanto, se pueden dibujar tipos diferentes de primitivas en un visual utilizando el contexto de dibujo, incluyendo geometría, datos de imagen y datos de video. La geometría es un tipo de clase que define una estructura de gráficos del vector sin trazar o llenar, es decir, un rectángulo. Cada objeto de geometría corresponde a una forma simple (LineGeometry, EllipseGeometry, RectangleGeometry) o una forma simple compleja (PathGeometry), o una lista de dichas formas (GeometryList) con una operación de combinación especificada (es decir, unión, cruce y así sucesivamente). Estos objetos forman una jerarquía de clase. También existen cortes para los dibujos utilizados frecuentemente en los tipos de geometría, tales como un método de DrawRectangle. Cuando es dibujada la geometría, un pincel o pluma pueden ser especificados. Un objeto de pincel define la forma en como llenar gráficamente un plano y existe una clase de jerarquía de objetos de pincel. Una pluma también tiene un pincel especificado en el mismo que describe la forma de como llenar un área trazada. Un tipo especial de objeto de pincel (el VisualBrush) puede hacer referencia a un visual para definir la forma en que el pincel va a ser dibujado. Un pincel de dibujo hace posible llenar una forma o controlarla con combinaciones de otras formas y pinceles. Otros beneficios y ventajas de la presente invención podrán ser apreciadas a partir de la siguiente descripción detallada, cuando es tomada en conjunto con los dibujos, en los cuales: Breve Descripción de los Dibujos La figura 1 es un diagrama de bloques que representa un sistema de computadora de ejemplo en el cual puede ser incorporada la presente invención; La figura 2 es un diagrama de bloques que representa generalmente una arquitectura de capa de gráficos en la cual puede ser incorporada la presente invención; La figura 3 es una representación de un gráfico de escena de los visuales y componentes asociados para el procesamiento del gráfico de escena, tal como atravesando el gráfico de escena para proporcionar comandos de gráfico y otros datos de acuerdo con un aspecto de la presente invención; La figura 4 es una representación de un gráfico de escena de visuales de validación, visuales de dibujo y Lista de instrucciones asociadas construidas de acuerdo con un aspecto de la presente invención; La figura 5 es una representación de una clase visual de un modelo de objeto, de acuerdo con un aspecto de la presente invención; La figura 6 es una representación de varios otros objetos del modelo de objeto, de acuerdo con un aspecto de la presente invención; La figura 7 es una representación de la jerarquía de clase de transformación, de acuerdo con un aspecto de la presente invención; Las figuras 8 y 9 son representaciones de transformaciones de un dato de visuales en una escala de geometría y una escala no uniforme, respectivamente, de acuerdo con un aspecto de la presente invención; La figura 10 es una representación de las clases de geometría del modelo de objeto, de acuerdo con un aspecto de la presente invención; La figura 11 es una representación de una estructura PathGeometry de acuerdo con un aspecto de la presente invención; La figura 12 es una representación de un gráfico de escena de los visuales y la lista de instrucciones que muestra gráficos de ejemplo producidos por las primitivas, de acuerdo con un aspecto de la presente invención; La figura 13 es una representación de las clases de pincel del modelo de objeto, de acuerdo con un aspecto de la presente invención; Las figuras 14 y 15 son representaciones de las gráficas presentadas que son el resultado de los datos en un objeto de pincel de gradiente lineal, de acuerdo con un aspecto de la presente invención; La figura 16 es una representación de los gráficos presentados que son el resultado de los datos en un objeto de pincel de gradiente radial, de acuerdo con un aspecto de la presente invención; La figura 17 es una representación de un objeto de pincel de nueve rejillas presentado de acuerdo con un aspecto de la presente invención. La figura 18 es una representación de los gráficos presentados que son el resultado de obtener varios valores de extensión de acuerdo con un aspecto de la presente invención; La figura 19 es una representación de gráficos presentados que son el resultado de tener diferentes valores de mosaico, de acuerdo con un aspecto de la presente invención; La figura 20 es una representación de una rejilla y una rejilla transformada que son el resultado de los datos en un objeto de pincel visual, de acuerdo con un aspecto de la presente invención; La figura 21 es una representación de la rejilla y la rejilla transformada con los gráficos presentados en las mismas dibujados a partir de un visual, de acuerdo con un aspecto de la presente invención. Descripción Detallada de la Invención ENTORNO DE OPERACIÓN DE EJEMPLO La figura 1 ilustra un ejemplo de un entorno de sistema de computación adecuado 100 en el cual puede ser implementada la presente invención. El entorno del sistema de computación 100 es solamente un ejemplo de un entorno de computación adecuado y no pretende sugerir cualquier limitación en lo que respecta al alcance del uso o funcionalidad de la presente invención. Ni debe de ser interpretado el entorno de computación 100 como que tiene dependencia alguna o requerimiento relacionado con cualquiera o una combinación de componentes ilustrados en el entorno de operación de ejemplo 100. La presente invención puede operar con otros sistemas, entornos o configuraciones de sistemas de computación diferentes de uso general o para propósitos especiales. Los ejemplos de los sistemas de computación bien conocidos, entornos y/o configuraciones que pueden ser adecuados para utilizarse con la presente invención incluyen, pero, no están limitados a, computadoras personales, computadoras de servidor, computadoras portátiles o manuales, aparatos de tableta, sistemas de multiprocesador, sistemas basados en microprocesador, descodificadores, componentes electrónicos programables por el consumidor, PCs de red, mini-computadoras, computadoras centrales, entornos de computación distribuidos que incluyen cualquiera de los sistemas o aparatos anteriores y similares. La presente invención se puede describir en el contexto general de las instrucciones ejecutables por computadora, tales como módulos de programa, siendo ejecutados por una computadora. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos y así sucesivamente, los cuales realizan tareas particulares o ¡mplementan tipos de datos abstractos particulares. La presente invención también puede ser practicada en entornos de computación distribuidos en donde las tareas son realizadas por aparatos de procesamiento remotos que están enlazados a través de una red de comunicaciones. En un entorno de computación distribuido, los módulos del programa pueden estar localizados tanto locales como en el medio de almacenamiento . de las computadoras remotas, incluyendo los aparatos de almacenamiento de memoria.

Haciendo referencia a la figura 1, un sistema de ejemplo para implementar la presente invención incluye un aparato de computación de uso general en la forma de una computadora 100. Los componentes de la computadora 110 pueden incluir, pero no están limitados, a una unidad de procesamiento 120 una memoria del sistema 130 y un bus del sistema 121 que conecta diferentes componentes del sistema, incluyendo una memoria del sistema a la unidad de procesamiento 120. El bus del sistema 121 puede ser cualquiera de varios tipos de estructuras de bus que incluyen un bus de memoria o controlador de memoria, un bus periférico y un bus local que utiliza cualquiera de una variedad de arquitecturas del bus. A modo de ejemplo, y no de limitación, dichas arquitecturas incluyen el bus de Arquitectura Estándar de la Industria (ISA), el bus de Arquitectura de Micro Canal (MCA), el bus mejorado ISA (EISA), el bus local de la Asociación de Estándares de Componentes Electrónicos de Video (VESA), el bus de Puerto de Gráficos Acelerado (AGP), y el bus de Interconexión de Componentes Periféricos (PCI) que también es conocido como un bus Mezanine. La computadora 110 incluye generalmente una variedad de medios legibles por computadora. El medio legible por computadora puede ser cualquier medio disponible al que se pueda tener el acceso por la computadora 110 e incluye tantos medio volátiles como no volátiles y medios removibles y no removióles. A modo de ejemplo y no de limitación, el medio legible por computadora puede comprender medios de almacenamiento de computadora y medios de comunicación. Los medios de almacenamiento de computadora incluyen tanto medios volátiles como no volátiles y removibles y no removibles implementados en cualquier método o tecnología para el almacenamiento de información, tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento de computadora incluyen pero no están limitados a memorias RAM, ROM, EEPROM, memorias instantáneas u otra tecnología de memorias, CD-ROM, discos digitales versátiles (DVD) u otro almacenamiento de discos ópticos, cassettes magnéticos, cintas magnéticas, almacenamiento de disco magnético u otros aparatos de almacenamiento magnéticos, y cualquier otro medio que pueda ser utilizado para almacenar la información deseada a la cual se puede tener acceso por medio de la computadora 110. Los medios de comunicación generalmente incorporan instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos en una señal de datos modulada, tal como una onda portadora u otro mecanismo de transporte e incluyen cualquier medio de entrega de información. El término "señal de datos modulados" significa una señal que tiene una o más de sus características ajustadas o cambiadas de un modo tal como para codificar la información en la señal. A modo de ejemplo y no de limitación, los medios de comunicación incluyen medios cableados, tales como redes cableadas o conexión cableada directa, y medios inalámbricos, tales como medios acústicos, F, infrarrojos y otros medios inalámbricos. Las combinaciones de cualquiera de los anteriores también deberán estar incluidas dentro del alcance de los medios legibles por computadora. La memoria del sistema 130 incluye medios de almacenamiento de computadora en la forma de una memoria volátil y/o no volátil, tal como una memoria solo de lectura (ROM) 131, y una memoria de acceso aleatorio (RAM) 132. Un sistema de entrada/salida básico 133 (BIOS), que contiene las rutinas básicas que ayudan a transferir la información entre los elementos dentro de la computadora 110, tales como durante el arranque y son generalmente almacenados en la memoria ROM 131. La memoria RAM 132 contiene generalmente datos y/o módulos de programa a los que se tiene acceso inmediatamente y/o que están siendo operados actualmente por la unidad de procesamiento 120. A modo de ejemplo y no de limitación, la figura 1 ilustra el sistema operativo 134, las aplicaciones de programa 135, otros módulos del programa 136 y los datos del programa 137. La computadora 110 también puede incluir otros medios de almacenamiento removibles/no removibles, volátiles/no volátiles. A modo solamente de ejemplo, la figura 1 ilustra una unidad de disco duro 141 que lee y escribe en medios magnéticos no removibles, no volátiles, una unidad de disco magnético 151 que lee y escribe en un disco magnético removible, no volátil 152, y una unidad de disco óptico 155 que lee y escribe en un disco óptico removible, no volátil 156 tal como un CD ROM u otros medios ópticos. Otros medios de almacenamiento de computadora removibles/no removibles, volátiles/no volátiles que pueden ser utilizados en el entorno operativo de ejemplo incluyen, pero no están limitados a, cassettes de cinta magnética, tarjetas de memoria instantánea, discos digitales versátiles, cintas digitales de video, RAM de estado sólido, ROM de estado sólido y similares. La unidad de disco duro 141 está conectada generalmente al bus de sistema 121 a través de una interfase de memoria no removible, tai como la interfase 140 y la unidad de disco magnético 151 y la unidad de disco óptico 155 generalmente están conectadas al bus de sistema 121 por medio de interfase de memoria removible, tal como la interfase 150. Las unidades de disco y sus medios de almacenamiento de computadora asociados, explicados anteriormente e ilustrados en la figura 1, proporcionan el almacenamiento de las instrucciones legibles por computadora, estructuras de datos, módulos del programa y otros datos de programa para la computadora 110. En la figura 1, por ejemplo, la unidad de disco duro 141 está ilustrada como el almacenamiento del sistema operativo 144, los programas de aplicación 145, otros módulos de programa 146 y los datos del programa 147. Observar que estos componentes pueden ser, ya sea el mismo o diferentes al sistema operativo 134, los programas de aplicación 135, otros módulos del programa 136 y el programa de datos 137. El sistema operativo 144, los programas de aplicación 145 u otros módulos de programas 146 y los datos del programa 147 tienen en la presente descripción diferentes números para ilustrar que, como un mínimo son copias diferentes. Un usuario puede ingresar comandos e información en la computadora 110 a través de los aparatos de entrada, tales como una tableta (digitalizador electrónico) 164, un micrófono 163, un teclado 162, un aparato de señalamiento 161 al que generalmente nos referimos como un ratón, una bola de rastreo, o una almohadilla de contacto. Otros medios de entrada (no mostrados) pueden incluir una palanca, una almohadilla de juegos, un plato de satélite, un escáner o similar. Estos y otros aparatos de entrada, con frecuencia son conectados a la unidad de procesamiento 120 a través de una interfase de entrada del usuario 160 que está conectada al bus del sistema, pero puede ser conectada por otra interfase y estructuras del bus, tales como un puerto paralelo, puerto de juegos o un bus de serie universal (USB). Un monitor 191 u otro tipo de aparato de pantalla también está conectado al bus de sistema 121 por medio de una interfase, tal como una interfase de video 190. El monitor 191 también puede estar integrado con un panel de pantalla de contacto 193 o similar que puede ingresar los datos digitalizados, tales como la escritura manual en el sistema de computadora 110 por medio de una interfase, tal como una interfase de pantalla de contacto 192. Observar que el monitor y/o el panel de pantalla de contacto puedan estar conectados físicamente a un alojamiento en el cual está incorporado el aparato de computación 110, tal como en una computadora personal de tipo de tableta, en donde el panel de pantalla de contacto 193 sirve esencialmente como la tableta 164. Además, las computadoras tales como el aparato de computadora 110 también pueden incluir otros aparatos de salida periféricos tales como bocinas 195 y la impresora 196, los cuales pueden ser conectados a través de una interfase periférica de salida 194 o similar. La computadora 110 puede operar en un entorno de red utilizando conexiones lógicas a una o más computadoras remotas, tales como la computadora remota 180. La computadora remota 180 puede ser una computadora personal, un servidor, un enrutador, una red de PC, un aparato igual u otro nodo de red común, y generalmente incluye muchos o todos los elementos descritos anteriormente en relación con la computadora 110, aunque solamente el aparato de almacenamiento de memoria 181 ha sido ilustrado en la figura 1. Las conexiones lógicas ¡lustradas en la figura 1 incluyen una red de área local (LAN) 171 y una red de área ancha (WAN) 173, pero también pueden incluir otras redes. Dichos entornos de red son un lugar común en las oficinas, en las redes de computadora de toda una empresa, las Intranets y la Internet. Cuando se utiliza en un entorno de red LAN, la computadora 110 es conectada a la LAN 171 a través de una ¡nterfase de red o adaptador 170. Cuando es utilizada en un entorno de red WAN la computadora 110 generalmente incluye un módem 172 u otros medios para establecer comunicaciones por la WAN 173, tal como la Internet. El módem 172, el cual puede ser interno o externo, puede estar conectado al bus del sistema 121 por medio de la inferíase de entrada del usuario 160 u otro mecanismo apropiado. En un entorno de red, los módulos del programa ilustrados en relación con la computadora 110, o porciones de los mismos pueden ser almacenados en un aparato de almacenamiento de memoria remoto. Por ejemplo y sin limitación, la figura 1 ilustra programas de aplicación remotos 185 como que residen en el aparato de memoria 181. Se podrá apreciar que las conexiones de red mostradas son de ejemplo y que se pueden utilizar otros medios para establecer un enlace de comunicaciones entre las computadoras. INTERFASES PARA LAS ESTRUCTURAS DE DATOS DE LOS GRÁFICOS DE ESCENA Un aspecto de la presente invención se dirige generalmente a permitir que un código de programa, tal como una aplicación u otro componente de sistema operativo, comunique instrucciones de dibujo y otra información (por ejemplo, mapas de bits de imagen) a los componentes de gráficos con el objeto de presentar salidas gráficas en la pantalla del sistema. Para este fin, la presente invención proporciona un número de funciones y métodos definidos, es decir, en la forma de interfases de programación de aplicación (APIs) para un modelo de objeto, que hace imposible que los programas llenen un gráfico de escena con estructuras de datos, primitivas de dibujo (comandos) u otros datos relacionados con los gráficos. Cuando es procesado, el gráfico de escena da como resultado gráficos que están siendo desplegados en la pantalla. La figura 2 representa una arquitectura en capas general 200 dentro de la cual puede ser ¡mplementada la presente invención. Tal y como se representa en la figura 2, el código del programa 202 (es decir, un programa de aplicación o un componente del sistema operativo o similar) puede ser desarrollado para producir datos de gráficos de una o varias maneras diferentes, incluyendo por medio de la elaboración de imagen 204, por medio de los elementos gráficos del vector 206 y/o por medio de invocaciones de función/método colocadas directamente en una capa de interfase de la programación de aplicación visual (API) 212, de acuerdo con un aspecto de la presente invención. En general, la elaboración de imágenes 204 proporciona al código del programa 202 un mecanismo para cargar, editar y guardar imágenes, es decir, mapas de bits. Como se describirá más adelante, estas imágenes pueden ser utilizadas por otras partes del sistema, y también existe un medio para utilizar los códigos de las primitivas de dibujo para dibujarlas directamente en una imagen. Los elementos gráficos del vector 206 proporcionan otro medio para dibujar gráficos, consistente con el resto del modelo de objeto (que se describirá más adelante). Los elementos gráficos del vector 206 pueden ser creados por medio de una marca del lenguaje, del cual un elemento/sistema de propiedad 208 y un sistema de distribución 210 interpretan para hacer las invocaciones apropiadas a la capa de API visual 212. Los elementos gráficos del vector 206 junto con el elemento/sistema de propiedad 208 y el sistema de distribución 210, se describen en la Solicitud de Patente Norteamericana Serie No. 10/401,717.

En una implementación, la arquitectura de capa de gráficos 200 incluye una composición de alto nivel y una máquina de animación 214, la cual incluye o está asociada de otro modo, con una estructura de datos para almacenamiento en la memoria temporal 216. La estructura de datos para almacenamiento en la memoria temporal 216 contiene un gráfico de escena que comprende objetos acomodados jerárquicamente que son administrados de acuerdo con un modelo de objeto definido, tal y como se describirá más adelante. En general, la capa visual API 212 proporciona el código del programa 202 (y el sistema de distribución 210) como una interfase para ia estructura de datos de almacenamiento en la memoria temporal 216, que incluye la capacidad de crear objetos, abrir y cerrar objetos para proporcionar datos a los mismos, y así sucesivamente. En otras palabras, la composición de alto nivel y la máquina de animación 240 exponen una capa API de medios unificada 212 por medio de la cual los desabolladores pueden expresar intenciones acerca de los gráficos y medios para desplegar información de gráficos, y proporcionan una plataforma subyacente con una información suficiente, de modo que la plataforma puede optimizar el uso del hardware para el código del programa. Por ejemplo, la plataforma subyacente actuará en respuesta al almacenamiento en la memoria temporal, la negociación de recursos y la integración de medios. En una ¡mplementación, la composición de alto nivel y máquina de animación 214 pasa una corriente de instrucción y posiblemente otros datos (por ejemplo, señaladores para los mapas de bits) a una máquina de animación y compuestos de bajo nivel rápido 218. Como se usa en la presente descripción, los términos "alto nivel" y "bajo nivel" son similares a aquellos utilizados en otros escenarios de computación, en donde en general, el más bajo de los componentes del software se relaciona con los componentes más altos, los componentes que se encuentran más cercanos al hardware. Por lo tanto, por ejemplo, la información de gráficos enviada de una máquina de animación y composición de alto nivel 214 puede ser recibida en la máquina de animación y composición de bajo nivel 218, en donde la información es utilizada para enviar datos de gráficos al subsistema de gráficos incluyendo el hardware 222. La composición de alto nivel y la máquina de animación 214 en conjunto con el código del programa 210 construyen un gráfico de escena para representar una escena de gráficos proporcionada por el código del programa 202. Por ejemplo, cada partida que va a ser dibujada puede ser cargada con instrucciones de dibujo, la cual puede almacenar en la memoria temporal del sistema en la estructura de datos gráficos de escena 216. Como se describirá más adelante, existe un número de modos diferentes para especificar esta estructura de datos 216, y lo que se ha dibujado. Además, la composición de alto nivel y la máquina de animación 214 se integra con temporización y sistemas de animación 220 para proporcionar un control de animación declaratorio (u otro) (es decir, intervalos de animación) y un control de temporización. Observar que el sistema de animación permite que los valores animados sean pasados esencialmente en cualquier parte del sistema, incluyendo por ejemplo, en el nivel de propiedad del elemento 208, dentro de la capa API visual 212, y en cualesquiera otros recursos. El sistema de temporización está expuesto en los niveles del elemento y visuales. La composición de bajo nivel y la máquina de animación 218 administra la composición, animando y presentando la escena, la cual entonces es proporcionada al subsistema de gráficos 222. La máquina de bajo nivel 218 compone las presentaciones para las escenas de aplicaciones múltiples, y con componentes de presentación, implementa la presentación real de los gráficos a la pantalla. Sin embargo, observar que algunas veces puede ser necesario y/o provechoso para algunas de las presentaciones, que sucedan en niveles más altos. Por ejemplo, aunque el servicio de las capas inferiores lo solicitan de las aplicaciones múltiples, las capas de nivel más alto son inicializadas en una base por aplicación, por lo que es posible por medio de los mecanismos de elaboración de imagen 204 realizar la presentación en niveles más altos que consumen tiempo o específicas de la aplicación, y pasar referencias a un mapa de bits para las capas inferiores. De acuerdo con un aspecto de la presente invención, una interfase de programación de aplicación visual (API) proporciona un conjunto de objetos que definen el árbol visual de acuerdo con un aspecto de la presente invención. El árbol visual representa una estructura de datos que puede ser presentada por el sistema de gráficos a un medio (una pantalla, impresora o superficie). Cuando son presentados los datos del árbol visual son la "escena" que puede ver un observador. Los objetos gráficos visuales (o simplemente visuales) contienen y administran los otros objetos gráficos que conforman una escena de dibujo como geometrías, primitivas, pinceles, gradientes de color y animaciones. Aunque la presente invención también proporciona acceso a los servicios de dibujo y presentación en un nivel más alto de abstracción utilizando un objeto más familiar y el sistema de propiedad y proporciona objetos gráficos del vector en el nivel de marca a través del lenguaje de marca ("XAML" denominado-código), la API visual será de mayor interés para los desabolladores quienes desean un control más grande sobre la funcionalidad del dibujo que ellos pueden lograr fácilmente utilizando el sistema de propiedad o la marca. Las figuras 3 y 4 muestran gráficos de escena de ejemplo 300 y 400, respectivamente que incluyen el objeto de base al que nos referimos como un visual. Los objetos visuales o simplemente visuales son contenedores para un contenido gráfico, tales como líneas, texto e imágenes. Como lo representa la herencia del objeto de las clases visuales en la figura 5, existen varios objetos visuales diferentes incluyendo el ContainerVisual, el cual es un visual que no contiene directamente el contenido gráfico, pero contiene objetos descendientes del DrawingVisual. Los objetos descendientes del DrawingVisual son agregados a un ContainerVisual en vez de a otros objetos DrawingVisual. Esto permite que el desarrollador haga cambios y establezca propiedades en los objetos visuales individuales sin volver a crearlos y luego volver a presentar el contexto completo del dibujo, mientras que también permite el acceso a las propiedades de sujeción y transformación en el objeto del contenedor. Los objetos ContainerVisual pueden ser anidados. Un DrawingVisual es un visual que puede contener contenido gráfico. Este visual expone un número de métodos de dibujo. Los objetos descendientes de un DrawingVisual son organizados en una base de cero, espacio de orden z. Un RetainedVisual es un visual A que introduce una "corriente de instrucciones retenidas" que puede ser utilizada para el dibujo. En términos más simples, el RetainedVisual permite que el desarrollador retenga el contenido visual y lo vuelva a dibujar solamente cuando es necesario. Es posible utilizar el RetainedVisual de manera imperativa, como un DrawingVisual, invocando el RenderOpen y utilizando el DrawingContext regresado para el dibujo. El RetainedVisual proporciona el recordatorio de la funcionalidad de recordatorio de validación y un método InvalidateVisual para utilizar la funcionalidad de validación, el usuario implementa la interfase IRetainedRender en el RetainedVisual o una clase que se deriva del mismo. Regresando a la figura 5, todavía otro visual es un HwndVisual 505, el cual es un visual utilizado para alojar un legado de control o ventana Microsoft® Win32® como un visual descendiente dentro de una escena visual de un gráfico de escena. Más particularmente, los programas de legado todavía operarán por medio de un método WM_PAINT (o similar) que dibuja en un Hwnd descendiente (o similar) basado en la tecnología de gráficos anterior. Para soportar dichos programas en el modelo nuevo de procesamientos gráficos, el HwndVisual permite que el Hwnd esté contenido en el gráfico de escena y sea movido conforme se vuelve a colocar el visual de origen. También son factibles otros tipos de visuales, tales como visuales tridimensionales (3D) los cuales hacen posible una conexión entre los mundos bidimensional y tridimensional, es decir, que es posible una visión similar a una cámara por medio de un visual bidimensional que tiene una visión dentro de un mundo tridimensional. Como se muestra en la figura 3, un VisualManager 304 comprende un objeto que conecta un árbol visual a un medio. El VisualManager establece una conexión retenida entre la estructura de datos visuales (el visual de raíz 302) y el objetivo al cual van a ser presentados los datos, ofreciendo la posibilidad de rastrear las diferencias entre los dos. El VisualManager 304 recibe mensajes de ventana y proporciona métodos para transformar un punto en las coordenadas del dibujo para divisar las coordenadas y viceversa. Una aplicación típica podría ser dibujar gráficos definiendo una distribución en el "XAML" tal y como se describió en la Solicitud de Patente Norteamericana Serie No. 10/401,717 mencionada anteriormente, y también especificando algunas operaciones de dibujo en el C#. Los desabolladores pueden crear elementos de Forma, o dibujar geometrías utilizando las clases Geometry con primitivas. En el escenario siguiente, el código demuestra el dibujo de una elipse en un visual subyacente en el Canvas: espacio privado CreateAndShowMainWindow ( ) { mainWindow = nuevo MSAvalon.Windows.Window ( ) ; Canvas myCanvas = nuevo Canvas ( ) ; mainWindow.Chiidren.Agregar(myCanvas) ; Ellipse e1= nueva Elipse ( ) ; el.Fill = Pinceles.Azul; el.Stroke = Pinceles. Negro; e1.StrokeThickness = nueva Longitud (10) ; el.CenterX = nueva Longitud (100) ; e1. CenterY = nueva Longitud (75); e1.RadiusX= nueva Longitud (50) ; e1.RadiusY = nueva Longitud (50) ; myCanvas.Children.Agregar(el); mainWindow.Mostrar ( ) ; } Utilizando la API Visual los desabolladores pueden, en vez de ello, dibujar directamente en el Visual (al que se tendría acceso de otro modo por medio del elemento de distribución). Para presentar el contenido de un objeto DrawingVisual, una aplicación generalmente invoca el método RenderOpen en el DrawingVisual. RenderOpen regresa a DrawingContex con el cual la aplicación puede realizar las operaciones de dibujo. Para borrar los contenidos del Visual, la aplicación invoca Cióse en el DrawingContex. Después de que la aplicación invoca Cióse el DrawingContex ya no podrá ser usado. El siguiente código dibuja una elipse (la misma elipse que en el ejemplo anterior) en un DrawingVisual, utilizando el objeto Geometry, en vez de la forma de elipse. El ejemplo crea un DrawingVisual, obtiene el DrawingVisual's DrawingContex, e invoca el método el DrawGeometry del DrawingContex's para dibujar la elipse. Observar que se debe agregar el Visual al largo de visuales del objeto en el nivel superior, ei cual en este caso es la ventana. mainWindow = nuevo MSAvalon.Windows.Window (') ; mainWindow.Mostrar ( ) ; DrawingVisual myDrawingVisual = DrawingVisual ( ) ; DrawingContext myDrawingContext myDrawingVisual. RenderOpen ( ) ; SolidColorBrush mySolidColorBrush = nuevo SolidColorBrush (); mySolidColorBrush. Color = Colores.Azul ; Pen myPen = nueva Pluma(PinceIes.Negro, 10) EllipseGeometry aGeometry = nuevo EllipseGeometry (nuevo Punto (100, 75), 50, 50); myDrawingContext.DrawGeometry(mySolidColorBrush, myPen, aGeometry) ; myDrawingContext.Cerrar ( ) ; ( (IVisual) mainWindow) . Children.Agregar(myDrawingVisual El ejemplo siguiente además construye un ejemplo previo agregando elipses similares a un ContainerVisuai; observar que este ejemplo tiene demasiada explicación por razones de claridad). Utilizando el ContainerVisuai se puede ayudar a organizar objetos de escena y permitir que el desarrollador separe los objetos Visuales en los cuales va a realizar la prueba de recuperación o validación (objetos RetainedVisual) del contenido ordinario dibujado y minimiza el nuevo dibujo del contenido innecesario. mainWindow = nuevo MSAvalon.Windows.Window ( ) ; mainWindow.Muestra ( ) ; / / Crear algunas Visuales ContainerVisuai myContainer = nuevo ContainerVisuai ( ) ; DrawingVisual myDrawingVisual = nuevo DrawingVisual ( ) ; DrawingVisual myDrawingVisuaM = nuevo DrawingVisual ( ) ; DrawingVisual my DrawingVisual_2 = nuevo DrawingVisual ( ) ; / / Hacer algún dibujo DrawingContext myDrawingContext = myDrawingVisual.RenderOpen ( ) ; SolidColorBrush mySolidColorBrush = nuevo SolidColorBrush ( ) ; mySolidColorBrush.Color = Colores.Violeta; Pen myPen = nueva Pluma (Pinceles. Negro, 10) ; EllipseGeometry aGeometry = nuevo EllipseGeometry (nuevo Punto (100, 75), 50, 50) ; myDrawingContext.DrawGeometry(mySolidColorBrush, myPen, aGeometry) ; myDrawingContext.Cerrar ( ) ; DrawingContext myDrawingContext_1 = myDrawingVisual_1.RenderOpen ( ) ; mySolidColorBrush.Color = Colores. Rojo; Pen myPenl = nueva Pluma(Pinceles.Naranja, 10) ; EllipseGeometry aGeometryl = nuevo EllipseGeometry(nuevo Punto (100, 175), 50, 50) ; myDrawingContexM .DraGeomeiry(mySolidColorBrush, myPenl, aGeometryl) ; myDrawingContexM .Cerrar ( ) ; DrawingContext myDrawingContext_2 = myDrawingVisual_2.RenderOpen ( ) ; mySolidColorBrush.Color = ColoresAmarillo; Pen myPen2 = nueva Pluma (Pinceles.Azul, 10) ; EllipseGeometry aGeometry2 = nuevo EllipseGeometry(nuevo Punto (100, 275), 50, 50); myDrawingContext_2.DrawGeornetry(mySolidColorBrush, myPen2, aGeometry2) ; myDrawingContext_2.Cerrar ( ) ; / / Agregar DrawingVisuals a la VisualCollection del ContainerVisuai myContainer.Children.Agregar(myDrawingVisual) ; myContainer.Children.Agregar(myDrawingV¡sual_1 ) ; myContainer.Criildren.Agregar(myDraw¡ngVisual_2) ; / / Agregar el ContainerVisuai a la ventana ( (IVisual)mainWindow).Children.Agregar(myContainer) ; Un RetainedVisual es similar al DrawingVisual, pero permite que se vuelva a dibujar de manera selectiva el contenido visual. Como lo sugiere su nombre, el RetainedVisual puede retener el contenido para apariencias múltiples en el medio. También proporciona la funcionalidad de recordatorio y validación. Esta funcionalidad puede ayudar cuando se presenta el dibujo ofreciendo al desarrollador un control mayor sobre el contenido que se vuelve a presentar. En un nivel básico, el usuario puede crear y utilizar un RetainedVisual más como un DrawingVisual; es decir, que el usuario puede invocar RenderOpen y obtener un DrawingContex. Alternativamente, el usuario puede implementar la interfase I RetainedRender en el RetainedVisual. Haciéndolo así, el usuario asegura que el sistema de gráficos utilizará el valor establecido en la propiedad RenderBounds como los límites para el contenido que va a ser presentado en el IRetainedVisual. Invocar Render.

Cuando se presenta la escena, el sistema de gráficos examinará cualquier Visual descendiente. Si el valor de la propiedad RenderBounds indica que se necesitará un contenido Visual particular para presentar una escena, el sistema entonces invocará el I Retained Visual . Render para llenar el contenido del Visual, reemplazando cualquier contenido que ya se encuentra en la memoria. La aplicación también puede invocar directamente InvalidateVisual para borrar el contenido de un Visual. Si la aplicación no ha implementado el IRetainedRender en el RetainedVisual, cualquier invocación al InvalidateVisual, girará una excepción. El código siguiente ejemplifica una clase que incrementa el IRetainedRender en un RetainedVisual y dibuja sobre el mismo.

Rectángulo de clase pública : RetainedVisual, IRetainedRender { Rectangle (Color color, Rect rect) público { m_color = color ; m_rect = rect ; RenderBounds = rect; } espacio público SetColor(Color color) { m_color = color ; InvalidateVisual ( ) ; } espacio público Render (DrawingContext ctx) { ctx.DrawRectangle ( nuevo SolidColorBrush (m_color), invalidar, m_rect) ; } } La API Visual, igual que el resto del sistema de gráficos de la presente invención, es una API administrada y hace uso de las características típicas del código administrado, incluyendo el tecleado fuerte y la recolección de basura. También aprovecha la capacidad de aceleración del hardware para la presentación. Para acomodar a los desabolladores que trabajan con aplicaciones no administradas existentes, el API Visual proporciona una interoperabilidad limitada entre el sistema de gráficos presente y los servicios de presentación basados en el (GDI) la interfase del aparato Microsoft Windows® Graphics. Esta interoperabilidad permite que los desabolladores alojen las ventanas basadas en GDI en las aplicaciones de advertencia de Visual utilizando el objeto Visual Hwnd, escriban controles y expongan temas que están basados en los dibujos y presentación de la presente invención, pero todavía funciona en aplicaciones de herencia del GDI, y modifica las aplicaciones GDI basadas en HWND para aprovechar las nuevas características de presentación, incluyendo la aceleración del hardware y el modelo de color. El HwndVisual hace posible alojar el contenido del Win32 en una aplicación de advertencia Visual. Tal y como se representa en la figura 5, el HwndVisual se hereda del ContainerVisual. Observar que no es posible mezclar el GDI y los nuevos modelos de dibujo en el mismo HwndVisual. En vez de ello, el visual podría ser más útil para controles del legado de un alcance limitado. El ejemplo siguiente demuestra la creación de un control en un HwndVisual y lo agrega al árbol visual.

/ / Importar los recursos del Win32 y definir variables para un control.

/ /Crear el control. hwndControl = CreateW¡ndowEx( 0, WC_TREEVIEW, WS_CHILD I WS_VISIBLE | TVS_HASLINES | TVS_LINESATROOT | TVS_HASBUTTONS, x, y. cyj hwndParent, IntPtr.Zero, IntPtr.Zero, 0); / / Crear un HwndVisual para el control y agregarlo a uno definido anteriormente / / collection. s_visua11 = HwndVisual. GetHwndVisual (hwndControl) ; s_visua11.Size = nuevo Tamaño (150, 150) ; s_visua11.IsHwndDpiAware = falso ; s_visua10.Children.Agregar(s_visua11) ; Igual que con otros objetos, se pueden aplicar transformaciones y otros cambios de propiedad al control una vez que está alojado en un Visual.

TransformCollection t = nuevo TransformCollection ( ) ; t.AddScale(1.4, 1.4); t.AddTranslate (130, 80); s_visua10.Children.SetTransform(s_visua11, t) ; Tal y como se representó en la figura 3, el Visual 302 del nivel superior (o raíz), está conectado a un objeto administrador de Visual 304, el cual también tiene una relación (por ejemplo, por medio de una manija) con una ventana (HWnd) 306, o una unidad similar en la cual los datos de gráfico son producidos para el código del programa. El VisualManager 304 administra el dibujo del Visual del nivel superior (y cualesquiera descendientes de esos Visuales), para esa ventana 306. La figura 6 muestra el VisualManager como uno de un conjunto de objetos 600 en el modelo de objeto el sistema de gráficos, aquí descrito. Para dibujar, el administrador del Visual manager 304 procesa (es decir, atraviesa o transmite) el gráfico de escena tal y como está programado por un despachador 308, y proporciona instrucciones gráficas y otros datos al componente de nivel bajo 218 (figura 2) para su ventana 306 correspondiente, tal y como se describió generalmente en las Solicitudes de Patentes Norteamericanas anteriormente mencionadas. El procesamiento del gráfico de escena generalmente será programado por un despachador 308 en un índice que es relativamente más lento que un índice de recordatorio del componente del nivel inferior 218 y/o el subsistema de gráficos 222. La figura 3 muestra un número de descendientes Visuales del 310 al 314 acomodados de manera jerárquica debajo del Visual 302 de alto nivel (raíz) y algunos de los cuales están representados como que han sido llenados por medio de contextos de dibujo 316, 318 (mostrados en los cuadros con guiones para representar su naturaleza temporal) con las listas de instrucciones asociadas 318 y 319, respectivamente, es decir, conteniendo Listas de Instrucciones y otros Visuales. Los Visuales también pueden contener otra información de propiedad. En general, la mayor parte de los accesos a la clase básica de visuales se hace por medio de una interfase IVisual, y el visual se deriva del DependencyObject, tal y como se representó en la figura 5. Entre otras primitivas de dibujo, la lista de instrucciones puede incluir una referencia a un ImageData. Ese ImageData puede entonces ser cambiado/actualizado directamente, obteniendo un contexto de dibujo fuera del mismo o teniendo un SurfaceVisualRenderer (denominado alternativamente ImageDataVisualRenderer). Los Visuales ofrecen servicios proporcionando sujetadores, opacidad, y posiblemente otras propiedades que pueden ser ajustadas y/o leídas por medio de un método de obtención. Además, el visual tiene señalizaciones que controlan la forma en que participa en la prueba de recuperación. Una propiedad de Mostrar es adecuada para mostrar/ocultar el visual, es decir, cuando es visual falso es invisible, y de otro modo el visual es visible. Además, estos objetos (ya sea que sean Visuales en la capa API Visual o elementos en la capa de elementos) existen en una jerarquía. Un sistema de coordenadas es heredado de manera descendente a través de esta jerarquía. De este modo, un visual de origen puede impulsar una transformación de coordenadas que modifica el paso de la presentación y obtiene y hace que se apliquen los descendientes a dicho visual de origen.

La transformación para un visual se encuentra en la conexión con ese visual. En otras palabras, se ajusta por medio del [Get| Set| ChildTransform en la interfase IVisual origen. Observar que las transformaciones de la coordenada pueden ser aplicadas de una manera uniforme a todo, como si estuvieran en un mapa de bits. Observar que esto no significa que las transformaciones siempre serán aplicables a los mapas de bits, pero que se llega a presentar es afectado por las transformaciones de una manera igual. A modo de ejemplo, si el usuario dibuja un círculo con una pluma redonda que es de un ancho de 2.54 cm (una pulgada) y luego aplica una escala en la dirección X de dos a dicho círculo, la pluma entonces será de 5.08 cm (2 pulgadas) de ancho a la izquierda y a la derecha y solamente 2.54 cm (una pulgada) de ancho en la parte superior y la inferior. A esto en algunas ocasiones nos referimos como una transformación de la composición o del mapa de bits (según está expuesto a una estructura o escala de geometría que afecta solamente la geometría). La figura 8 es una representación de la transformación de escala, con una imagen 800 no transformada que aparece a la izquierda y una imagen transformada 802 con una escala no uniforme que aparece a la derecha. Figura 9 es una representación de la transformación de escala, con una imagen 800 sin transformar que aparece a la izquierda y una imagen transformada 904 con el escalado de geometría que aparece a la derecha. Con respecto a la transformación de la coordenada de un visual, el TransformToDescendant transforma desde el visual de referencia a un visual descendiente. El punto es transformado desde el espacio de la coordenada de posttransformación del visual de referencia al espacio de coordenada posterior a la transformación del visual descendente. El TransformFromDescendant transforma un punto desde el visual descendente hasta la cadena de origen para los visuales de referencia. El punto es transformado desde el espacio de la coordenada posterior a la transformación del visual descendente al espacio de coordenada posterior a la transformación del visual de referencia. Un usuario puede obtener una matriz para y desde un descendiente para y desde un visual arbitrario. Están disponibles dos propiedades que pueden ser utilizadas para determinar el cuadro de límites del contenido del Visual, es decir, los DescendantBounds, los cuales se encuentran en el cuadro de límites de los descendientes y el ContentBounds el cual se encuentra en los límites del contenido. Aplicando una Union a estos se proporcionan los límites totales. La propiedad de sujetador establece (y obtiene) la región de sujeción de un visual. Se puede utilizar cualquier Geometry (la clase de geometría se muestra en la figura 10), como una región de sujeción y la región de sujeción es aplicada en el espacio de coordenada posterior a la transformación. En una ¡mpiementación, un establecimiento por omisión (default) para la región de sujeción es nulo, es decir que no hay sujeción, lo cual se puede considerar como un rectángulo de sujeción grande infinito de (-8, -8) a (+8, + 8). La propiedad Opacity obtiene/ajusta el valor de opacidad del visual, de modo que el contenido del visual es mezclado en la superficie de dibujo basado en el valor de opacidad y el modo de mezcla seleccionado. La propiedad Blend ode puede ser utilizada para ajustar (u obtener) el modo de mezcla que es utilizado. Por ejemplo, un valor de opacidad (alfa) puede ser ajustado entre 0.0 y 1.0, con un ajuste de mezcla alfa lineal como el modo, es decir, Color = alfa * color del fondo + (1.0-alfa) * color del fondo). Otros servicios, tales como las propiedades de efectos especiales pueden estar incluidas en un visual, por ejemplo, difuminación, cromo y así sucesivamente. Los diferentes servicios (incluyendo transformación, opacidad y sujeción), pueden ser impulsados y hacerlos surgir en el contexto de dibujo y las operaciones de impulso/aparición pueden estar anidadas, siempre que exista una invocación para la aparición apropiada para cada invocación de impulsar.

El método PushTransform impulsa una transformación. Las operaciones subsecuentes de dibujo son ejecutadas con respecto a la transformación impulsada. La invocación de aparición hace que aparezca la transformación impulsada por el acoplamiento de la Invocación PushTransform: espacio PushTransform (transformar Transform); espacio PushTransform (matriz Matrix); Espacio Aparición ();. De un modo similar, un método PushOpacity impulsa un valor de opacidad. Las operaciones de dibujo subsecuentes son presentadas en una superficie temporal con un valor de opacidad especificado y entonces compuestos dentro de una escena. El comando Pop (), hace surgir la opacidad impulsada por la invocación de acoplamiento de PushOpacity: espacio PushOpacity (flotar opacidad); espacio PushOpacity (opacidad FloatAnimation); espacio Presentación ();.

El método PushClip impulsa la geometría de sujeción; las operaciones de dibujos subsecuentes son sujetadas a la geometría. La sujeción es aplicada en el espacio posterior a la transformación. El comando Pop (), hace aparecer la región de sujeción impulsada por la invocación de acoplamiento PushClip: espacio PushClip (sujeción de Geometry); espacio Pop ();. Observar que las operaciones de impulso pueden ser anidadas de manera arbitraria siempre que las operaciones de presentación estén acopladas con un impulso. Por ejemplo, lo siguiente es válido: PushTransform(...) ; DrawLine(...) ; PushClip(...) ; DrawLine(...) ; Pop(); PushTransform(...) ; DrawRect(...) ; Pop ( ) ; Pop ( ) ; Un ProxyVisual puede ser agregado más de una vez en gráficos de escena, es decir, debajo de un visual contenedor. Como cualquier visual al que nos referimos por un ProxyVisual puede ser alcanzado por trayectorias múltiples desde la raíz, lee los servicios (TransformToDescendent, TransformFromDescendent y HitTest) no funciona a través de un ProxyVisual. En la escena existe una trayectoria canónica de cualquier visual a la raíz del árbol visual y esa trayectoria no incluye ProxyVisuals algunos. La figura 4 muestra un gráfico de escena de ejemplo 400 en el cual los ContainerVisuals y los DrawingVisuals (y otros) están relacionados en el gráfico de escena y tienen datos asociados en la forma de Listas de Instrucción, (es decir, en los contextos correspondientes del dibujo). El ContainerVisual es un contenedor para los Visuales y los ContainerVisuals pueden ser anidados dentro de ellos. Los descendientes de un ContainerVisual pueden ser manipulados mediante métodos en la ¡nterfase IVisual que implementa el ContainerVisual. El orden de los Visuales en el VisualCollection determina en qué orden son presentados los Visuales, es decir, los Visuales son presentados desde el índice más bajo hasta el índice más alto, y desde atrás hacia delante (orden de pintura). Tal y como se describió anteriormente, los visuales pueden ser dibujados llenando sus contextos de dibujo con diferentes primitivas de dibujo, incluyendo Geometry, ImageSource y MediaData. Además, existe un conjunto de recursos y clases que son compartidas a través de esta pila completa. Esto incluye, Plumas, Pinceles, Geometría, Transformaciones y Efectos. La clase abstracta de DrawingContex expone un conjunto de operaciones de dibujo que pueden ser utilizadas para poblar un DrawingVisual, ValidationVisual, ImageData, etc. En otras palabras, la clase abstracta del contexto de dibujo expone un conjunto de operaciones de dibujo; por cada operación de dibujo existen dos métodos, uno que toma constantes como argumentos, y uno que toma animadores como argumentos. Geometry es un tipo de clase (figura 10) que define una estructura de gráficos de vector, sin trazos o llenado. Cada objeto geometry es una forma simple (LineGeometry, EllipseGeometry, RectangleGeometry), una forma compleja sola (PathGeometry) o la lista de dichas formas GeometryCollection con una operación de combinación (por ejemplo, unión, cruce y así sucesivamente) especificada. Estos objetos forman una jerarquía de clase, tal y como se representa en la figura 10. Tal y como se representa en la figura 11, el PathGeometry es una colección de objetos de figura. A la vez, cada uno de los objetos de la figura está compuesto de uno o más objetos de Segmentos, el cual realmente define la forma de la figura. Una figura es una sub-sección de un Geometry que define una colección de segmentos. Esta colección de segmentos es una serie única conectada de objetos de Segmento bidimensionales. La figura puede ser, ya sea de forma cerrada con un área definida, o solamente una serie conectada de Segmentos que define una curva, pero no es un área cerrada. Tal y como se representa en la figura 12, cuando es dibujada la geometría (es decir, un rectángulo), un pincel o pluma puede ser especificado, tal y como se describirá más adelante. Además, el objeto de pluma también tiene un objeto de pincel. El objeto de pincel define la forma y como llenar gráficamente un plano, y existe una jerarquía de clase de objetos de pincel. Esto es representado en la figura 12, por el rectángulo lleno 1202, que es el resultado cuando es procesado el visual que incluye el rectángulo y las instrucciones y parámetros del pincel. Un objeto de pluma se sostiene en un pincel junto con las propiedades para el Width, LineJoin, LineCap, MiterLimit, DashArray y DashOffset, tal y como se describirá más adelante. También se describirán más adelante, unos tipos de tamaños de pinceles (tales como gradientes y nueve rejillas) por ellos mismos. Cuando son utilizados, el tamaño para estos pinceles es obtenido de una caja de límites, es decir, cuando el GradientUnits/DestinationUnits para el pincel es ajustado a RelativeToBoundingBox, se utiliza la caja de límites de la primitiva está siendo dibujada. Si esas propiedades son ajustadas en Absolute, entonces se utiliza el espacio de coordenadas. El modelo de objeto de gráficos de la presente invención incluye un modelo de objeto de Brush, el cual generalmente está dirigido hacia el concepto de la cobertura de un plano con pixeles. Los ejemplos de tipo de pinceles son representados en la jerarquía de la figura 3 y, bajo una clase clásica Brush que incluyen Gradient Brush, NineGridBrush, SolidCoIorBrush y TileBrush. El GradientBrush incluye los objetos LinearGradient y RadialGradient. El DrawingBrush y el ImageBrush se derivan del TileBrush. Es factible hacer adaptaciones alternativas de las clases, es decir, el TileBrush puede ser derivado del ImageBrush, el VisualBrush, el VideoBrush, el NineGridBrush y el Drawing Brush. Observar que ios objetos Brush pueden reconocer las forma en que se relacionan con los sistemas de coordenadas cuando son utilizados, y/o la forma en que se relacionan con los cuadros de límites de la forma en las cuales son utilizados. En general, la información tal como el tamaño puede ser deducida del objeto en el cual está dibujado el pincel. De una manera más particular, muchos de los tipos de pinceles utilizan el sistema de coordenadas para especificar alguno de sus parámetros. Este sistema de coordenadas puede ser definido, ya sea como en relación con un cuadro de límites simple de la forma al cual es aplicado el pincel, o puede estar relacionado con el espacio de coordenadas que está activo en el momento que es utilizado el pincel. Estos son conocidos, respectivamente como el modo RelativeToBoundingBox y el modo Absolute. Un objeto SolidCoIorBrush llena el plano identificado con un color sólido. Si existe un componente alfa del color, éste es combinado a modo de identificación con el atributo correspondiente de opacidad en la base clásica Brush. Lo siguiente establece un ejemplo del objeto SoiidColorBrush: Los objetos GradientBrush, o simplemente gradientes, proporcionan un llenado de gradiente y son dibujados especificando un conjunto de topes de gradiente, los cuales especifican los colores a lo largo de una clasificación de progreso. El gradiente es dibujado realizando interpolaciones lineales entre los topes de gradiente en un espacio de color 2.2 RGB gamma; la interpolación entre algunos gammas y otros espacios de color (SHB, CMYK y así sucesivamente), y también es posible de una manera alternativa. Dos tipos de objetos de gradientes incluyen los gradientes lineales y radiales. En general, los gradientes están compuestos de una lista de topes de gradientes. Cada uno de estos topes de gradientes contiene un color (con valores alfa incluidos) y una compensación. Si no existen topes de gradientes especificados, el pincel se dibuja como un negro transparente sólido, como si no existiera pincel alguno especificado. Si existe solamente un tope de gradiente especificado, el pincel es dibujado como un color sólido con un color especificado. Otras clases de fuente de recursos, la clase de tope del gradiente, (ejemplo en la tabla siguiente) se deriva de una clase que se puede cambiar y por lo tanto, se puede mutar de manera selectiva, tal y como se describió en la Solicitud de Patente Norteamericana Titulada "Clase Cambiable y Patrón para Proporcionar la Mutabilidad Selectiva en Entornos de Programación de Computación". Los gradientes son dibujados especificando un conjunto de topes de gradientes. Estos topes de gradientes especifican los colores a lo largo de una clasificación de progreso. Existen dos tipos de gradientes soportados actualmente, es decir, los gradientes lineales y radiales. El gradiente es dibujado haciendo interpolaciones entre los topes de gradiente en el espacio de color especificado. Los gradientes están compuestos de una lista de topes de gradientes. Cada uno de estos topes de gradientes contiene un color (con los valores alfa incluidos) y una compensación. Si no existen topes de gradiente especificados, el pincel es dibujado como transparente (como si no hubiera pincel especificado). Si solamente existe un tope de gradiente especificado, el pincel es dibujado como un color sólido con el color especificado. Se consideran cualesquiera topes de gradientes con compensación en un rango de cero a uno (0.0 . . . 0.0), estando el tope más grande en el rango (-8. . .0.0] y el tope más pequeño en el rango [1.0 . . . + 8). Si el conjunto de topes que está siendo considerado incluye un tope el cual está fuera del rango de cero a uno, se deriva un tope implícito en cero (y/o uno) el cual representa el color interpolado el cual ocurriría en este tope. También, si están establecidos dos o más topes en la misma compensación, ocurre una transición dura en esa compensación (en vez de ser interpolada). El orden en el cual los topes son agregados determina el comportamiento en esta compensación; el primer tope para ser agregado es el color efectivo antes de esa compensación, el último tope para ser establecido es el color efectivo después de este tope, y cualesquiera topes adicionales en esta compensación son ignorados. Esta clase es como una clase intercambiable u otras clases de recursos similares. clase pública sellada Systenn.Windows.Media.GradientStop : Cambiable { GradientStop ( ) público ; GradientStop(Color color, compensación doble) público ; GradientStop público (Color, color, ColorAnimationCollection colorAnimations, compensación doble, DoubieAnimationCollection offsetAnimations) ; nuevo GradientStop Copy( ) público; ??oculta Changeable.Copy ( ) / / El default es transparente [Animationf'ColorAnimations")] Color Color público { obtener; ajustar; } ColorAnimationCollection ColorAnimations público { obtener; ajustar; } //El default esO [Animationf'OffsetAnimations")] double Offset público { obtener; ajustar; } DoubleAnimationCollection OffsetAnimations público { obtener; ajustar; } } Igual que el SolidColorBrush , este tiene intercambiables anidados en las colecciones de animación. El GradientSpreadMethod enum especifica la forma en que será dibujado el gradiente fuera de los vectores o los espacios especificados. Existen tres valores posibles, incluyendo el de Pad, en el cual terminan los colores (el primero y el último) que son utilizados para llenar el espacio restante, Reflect, en el cual los topes se vuelven a utilizar en un orden inverso repetidamente para llenar el espacio, y el Repeat, en el cual los topes son repetidos en orden hasta que se ha llenado el espacio. El valor por omisión (default) para las propiedades de este tipo es Pad: System.Windows.Media.GradientSpreadMethod enum público { Pad, Reflejar, „ Repe ,tir Las figuras 14 y 15 proporcionan algunos ejemplos del GradientSpreadMethod, (aunque en escala de grises, en vez de ser en color). Cada forma tiene un gradiente lineal que va desde el blanco hasta el gris. La línea sólida representa el vector del gradiente. En general, se utiliza un LinearGradientBrush para llenar un área con un gradiente lineal. Un gradiente lineal define un gradiente a lo largo de una línea. El punto final de la línea es definido por las propiedades StartPoint y EndPoint del gradiente lineal. Por omisión (default), el StartPoint de un gradiente lineal es (0,0), siendo llenada la esquina superior izquierda del área y su EndPoint es (1, 1), siendo llenada el área de la esquina superior derecha. Tal y como se representó en la figura 15, utilizando los valores por omisión (default), los colores en el gradiente resultante son interpolados a lo largo de una trayectoria diagonal. La línea negra formada desde los puntos de inicio y final del gradiente han sido agregadas aquí para destacar la trayectoria de interpolación del gradiente. El Colorí nterpolation ode enum define el modo de interpolación para los colores dentro de un gradiente. Las dos opciones son PhysicallyLinearGamma 10 y PerceptualIyLinearGamma22.

ColorlnterpolationMode enum público { / / Los colores son interpolados en el espacio Gamma 1.0 PhysicallyLinearGammalO, / / Los colores son interpolados en el espacio Gamma 2.2 PerceptuailyLinearGamma22 Esta es u na cl ase básica a bstracta . clase pública abstracta System.Windows.Media.GradientBrush : Pincel { GradientBrush ( ) interno ; nuevo GradientBrush Copy ( ) público ; / / oculta el Changeabie.copy ( ) / / El default es " PerceptuailyL¡nearGamma22" ColorlnterpolationMode ColorlnterpolationMode público { obtener; ajustar; } // El default es RelativeToBoundingBox BrushMappingMode MappingMode público { obtener; ajustar; } / / El default es Pad GradientSpreadMethod SpreadMethod público { obtener; ajustar; } / / Topes del Gradiente espacio público AddStop(Color color, compensación doble) ; GradientStopCollection GradientStops público { obtener; ajustar; } / / ColorlnterpolationMode ColorlnterpolationMode ColorlnterpolationMode público { obtener; ajustar; } Como se describió anteriormente, en la sección de Changeables el GradientBrush es un tipo complejo con respecto a los cambiables, debido a que sus propiedades GradientStops mismas sostienen cambiables. Esto significa que el GradientBrush necesita implementar los métodos protegidos MakeUnchangeableCore (), y PropagateEventHandler (), así como CloneCore () que implementa las subclases cambiables. También se puede seleccionar implementar el ValidateObjectState () si existe por combinaciones invalidadas de los GradientStops que forman la colección, por ejemplo. El LinearGradient define un pincel de gradiente lineal a lo largo de un vector. Los topes individuales especifican los topes de color a lo largo de ese vector. clase pública sellada Systems.Windows. edia.LinearGradient : GradientBrush { LinearGradient ( ) público; / / ¡nicializa en transparente / / Prepara un gradiente con dos colores y un vector del gradiente // especificado para llenar el objeto el gradiente es aplicado a. / / Esto implica el RelativeToBoundingBox para las GradientUnits / / propiedad LinearGradient (Color colorí, Color color2, ángulo doble) público; LinearGradient (Color colorí, Color color2, Point vectorStart, Point vectorEnd) público ; nuevo LinearGradient Copy ( ) público ; ??ocultar Changeable.Copy ( ) / / Punto de Partida en el Vector del Gradiente / / El default es 0, 0 [Animation("StartPointAnimations")] Point StartPoint público { obtener; ajustar; } PointAnimationColIection StartPointAnimations público { obtener; ajustar; } I I El default es 1, 1 [Animation("EndPointAnimations")] Point EndPoint público { obtener; ajustar; } PointAnimationColIection EndPointAnimations público { obtener; ajustar; } } pincel del gradiente lineal: "HorizontalGradient" comma-wsp color comma-wsp color I "VerticalGradienf ' comma-wsp color comma-wsp color | "LinearGradient" comma-wsp coordinate-pair comma-wsp color comma-wsp color La marca para el LinearGradient permite la especificación LinearGradient con dos topes de color, en compensaciones cero y uno. Si se utiliza la versión "LinearGradient", el punto de inicio y el punto final son especificados, respectivamente. Si se utiliza el "HorizontalGradient", el punto de inicio es ajustado en 0,0 y el punto final es ajustado en 1,0. Si se utiliza el "VerticalGradient" el punto de inicio es ajustado en 0,0 y el punto final es ajustado en 0,1. En estos casos, se utiliza el MappingMode por omisión (default), el cual es RelativeToBoundingBox. El RadialGradient es similar en el modelo de programación al gradiente lineal. Sin embargo, siempre que el gradiente lineal tiene un punto de inicio y un punto final para definir el vector del gradiente, el gradiente radial tiene un círculo junto con un punto de enfoque para definir el comportamiento del gradiente. El círculo que define el punto final del gradiente -en otras palabras, un tope del gradiente en 1.0 define el color en la circunferencia del círculo. El punto de enfoque define el centro del gradiente. Un tope de gradiente en 0.0 define el color en el punto de enfoque. La figura 16 representa un RadialGradient que va del blanco al gris (en escala de grises). El círculo exterior representa el círculo de gradiente mientras que el guión sólido indica el punto de enfoque. Este gradiente tiene un ajuste Spread Method para Pad . clase pública sellada System. Windows.Media.RadialGradient : GradientBrush { RadialGradient ( ) público; / / inicializa en transparente / / Prepara un gradiente con dos colores. / / Este implica el RelativeToBoundingBox para las GradientUnits / / propiedad junto con un centro en (0.5, 0.5) / / un radio de 0.5 y un punto de enfoque en (0.5, 0.5) RadialGradient(Color colorí , Color color2) público ; nuevo RadialGradient Copy ( ) público ; / / oculta el Changeable.Copy ( ) / / El default es 0.5, 0.5 [Animation("CenterAnimations")] Point Center público { obtener; ajustar; } PointAnimationCollection CenterAnimations público { obtener; ajustar; } / / El default es 0.5 [Animation("RadiusXAnimations")] double RadiusX público { obtener; ajustar; } DoubleAnimationCollection RadiusXAnimations público obtener; ajustar; } / / El default es 0.5 [AnimationfRadiusYAnimations")] double RadiusY público { obtener; ajustar; } DoubleAnimationCollection RadiusYAnimations público obtener; ajustar; } // El default es 0.5, 0.5 [Animation("FocusAnimations")] Point Focus pública { obtener; ajustar; } PointAnimationCollection FocusAnimations público { obtener; ajustar; } } La marca para el RadialGradient permite la especificación de un RadialGradient con dos topes de color, en las compensaciones 0 y 1, respectivamente. Se utiliza el MappingMode por omisión (default), el cual es RelativeToBoundingBox, como son los radios por omisión (default) 0.5: pincel de gradiente radial: "RadialGradient" comma-wsp color comma-wsp color El TileBrush es una clase básica abstracta, la cual contiene la lógica para describir un mosaico y medios para que ese mosaico llene un área. La subclase del contenido contiene el TileBrush, y define lógicamente una forma para llenar un plano infinito. El Stretch enum es utilizado para describir la forma en que un ViewBox (espacio de la fuente de coordenada) es mapeado a un ViewPort (espacio de coordenada de destino). Éste es utilizado en el TileBrush: System.Windows.Stretch enum público { / / Conserva el tamaño original None, / / La proporción de aspecto no es conservada, el ViewBox llena el ViewPort Fill, / / La proporción de aspecto es conservada, El ViewBox es escalado de manera uniforme tan grande como sea / / posible de modo que tanto el ancho como la altura encajen dentro del ViewPort Uniform, / / La proporción de aspecto es conservada, el ViewBox es escalado de manera uniforme tan pequeño como sea / / posible de modo que el ViewPort completo sea llenado por el ViewBox UniformToFill } La figura 18 proporciona ejemplos de la proyección. En estos ejemplos, los contenidos son alineados en la parte superior/izquierda. El TileMode enum es utilizado para describir si, y como es llenado el espacio por los Mosaicos. Un TileBrush define en donde se encuentra el Mosaico de base (erspecificdo por el ViewPort). El resto del espacio es llenado basado en el valor TileMode.

Systems.Windows. edia.TileMode enum público { / / No forma mosaico - sólo se dibuja el mosaico básico, el área restante se / / deja como transparente None, / / El modo de mosaico básico - el mosaico básico es dibujado y el área restante / / es llenada repitiendo el mosaico básico de modo que ei extremo derecho de un / / mosaico empalma el extremo izquierdo del siguiente, y de un modo similar Tile, / / Igual que el mosaico, pero saltan horizontalmente las columnas alternadas / / de mosaicos. El mosaico básico es dibujado sin transformar. FlipX, / / Igual que el mosaico, pero las filas alternadas de mosaicos saltan verticalmente / / El mosaico se dibuja sin transformar. FlipY, / / La combinación de FlipX y FlipY. El mosaico básico es dibujado / / sin transformar FlipXY } La fig u ra 1 9 pro porcio na ejempl os del TileMode. El mosai co superior del extrem o izq u ierdo en cada ejem pl o es el mosaico básico . Estos ejem plos representan None, Tile, Fl ipX, Fli pY y Fl i pXY.

El VerticalAlignment enum es utilizado para describir la forma en que es colocado el contenido dentro de un contenedor de manera vertical: System.Windows.VerticalAlignment enum público { / / Alinear el contenido hacia la parte superior de un espacio , / / Centrar el contenido verticalmente , / / Alinear el contenido hacia la parte inferior de un espacio , El HorizontalAlignment enum es utilizado para describir la forma en que es colocado el contenido dentro de un contenedor de manera horizontal.

System.Windows.HorizontalAlignment enum público { / / Alinear el contenido hacia la izquierda de un espacio / ¡ Centrar el contenido horizontalmente , / / Alinear el contenido hacia la derecha de un espacio , } Las propiedades TileBrush seleccionan una porción rectangular del plano infinito para que sea un mosaico (el ViewBox), y describen un rectángulo de destino (ViewPort) el cual será el Mosaico básico en el área que está siendo llenada. El área de destino restante será llenada basada en la propiedad Ti leMode , la cua l co ntro la si la fo rma en el mosai co orig i n a l es d u pl icada pa ra l lenar el espaci o resta nte: clase pública abstracta System.Windows.Media.TileBrush : Brush { nuevo TiieBrush Copy ( ) público ; / / oculta el Brush.Copy ( ) / / El default es RelativeToBoundingBox BrushMappingMode ViewPortUnits público { obtener; ajustar; } / / El defauit es RelativeToBoundingBox BrushMappingMode ContentUnits público {obtener; ajustar; } / / El default es Rect.Empty [Animation("ViewBoxAnimations")] Rect ViewBox público { obtener; ajustar; } RectAnimationCollection ViewBoxAnimations público { obtener; ajustar; } // El default es Fill Strech Stretch público { obtener; ajustar; } / / El default es None TileMode TileMode público { obtener; ajustar; } / / El default es Center HorizontalAlignment HorizontalAlignment público { obtener; ajustar; } / / El default es Center VerticalAlignment VerticalAlignment público { obtener; ajustar; } // El default es O, 0, 1, 1 [Animat¡on("ViewPortAnimations")] Rect ViewPort público { obtener; ajustar; } RectAnimationCollection Vie PortAnimations público { obtener; ajustar; } } Los contenidos del TileBrush no tienen límites intrínsecos y describen de manera efectiva un plano infinito. Estos contenidos existen en su propio paso de coordenadas, y el espacio el cual está siendo llenado por el TileBrush es el espacio local de coordenadas en el momento de la aplicación. El espacio de contenido es mapeado dentro del espacio local basado en las propiedades del ViewBox, ViewPort, Alignments y Stretch. El ViewBox es especificado en el espacio de contenido, y este rectángulo es mapeado dentro de un rectángulo ViewPort. El ViewPort define la localización en donde serán dibujados eventualmente los contenidos, creando el mosaico básico para este pincel. Si el valor del ViewPortUnits es Absolute, el valor del ViewPort es considerado como que se encuentra en el espacio local en el momento de la aplicación, si en vez de ello, el valor del ViewPortUnits es un valor RelativeToBoundingBox, entonces el valor del ViewPort es considerado que se encuentra en el espacio de coordenadas en donde 0,0, es la esquina superior/izquierda del cuadro de límites del objeto que está siendo pintado, y 1,1 es la esquina inferior/derecha del mismo cuadro. Por ejemplo, considerar que se está llenando un RectangleGeometry el cual es dibujado del 100, 100 a 200, 200. Entonces, si el ViewPortUnits es Absoluto, se describiría un ViewPort de (100, 100, 100, 100) en el área de contenido total. Si el ViewPortUnits es RelativeToBoundingBox, un ViewPort de (0,0,1,1) describiría el área de contenido total. Si el tamaño del ViewPort está vacío y el Stretch no es None, el pincel produce nada. El ViewBox es especificado en el espacio de contenido. Este rectángulo es transformado para que se adapte dentro del ViewPort, según sea determinado por las propiedades de alineación y la propiedad Stretch. Si el Stretch es None, no se aplica escalación al contenido. Si el Stretch es FUI, entonces el ViewBox es escalado independientemente en ambos X e Y para que sea del mismo tamaño que el ViewPort. Si el Stretch es uniforme o UniformToFill, la lógica es similar, pero las dimensiones X e Y son escaladas de manera uniforme, conservando la proporción de aspecto del contenido. Si el Stretch es Uniform, el ViewBox es escalado para que tenga una dimensión más restringida igual al tamaño del ViewPort. Si el Stretch es UniformToFill, el ViewBox es escalado para que tenga una dimensión menos restringida igual al tamaño del ViewPort. Otro modo para pensar acerca de esto, es que tanto el Uniform como el UniformToFill conservan la proporción del aspecto, pero el Uniform asegura que el ViewBox completo está dentro del ViewPort (dejando potencialmente porciones del ViewPort sin cubrir por ViewBox), y el UniformToFill asegura que el ViewPort completo es llenado por el ViewBox (ocasionando potencialmente porciones del ViewBox que van a estar fuera del ViewPort). Si el área del ViewBox está vacía, entonces no se aplica Stretch. La alineación ocurrirá todavía y éste se colocará en "punto" ViewBox. Una vez que el ViewPort es determinado (basado en el ViewPortUnits) y el tamaño del destino del ViewBox es determinado (basado en el Stretch), el ViewBox necesita ser colocado dentro del ViewPort. Si el ViewBox es del mismo tamaño que el ViewPort (si el Stretch es Fill (lleno) o si solo pudiera ocurrir con uno de los otros tres valores de Stretch), entonces el ViewBox es colocado en el origen como para que sea Idéntico al ViewPort. Si no es así, entonces se consideran el HorizontalAlignment y el VerticalAIignment. Basados en estas propiedades, el ViewBox es alineado tanto en la alineación X como en la Y. Si el HorizontalAlignment es izquierdo, entonces el extremo izquierdo del ViewBox será colocado en el extremo izquierdo del ViewPort. Si es en el centro, entonces el centro del ViewBox será colocado en el centro del ViewPort, y si es a la derecha entonces se encontrará el extremo derecho. El proceso se repite para la dimensión Y. Si el ViewBox es Empty es considerado como no fijado. Si no está fijado, entonces son consideradas las ContentUnits. Si las ContentUnits son Absolute, no ocurre compensación o escalacion y los contenidos son dibujados en el ViewPort sin transformarlos. Si las ContentUnits son RelativeToBoundingBox, entonces el origen del contenido es alineado con el ViewPort Origin y los contenidos son escalados por el ancho y el alto del cuadro de límites del objeto. Cuando se llena un espacio con el TileBrush, los contenidos son mapeados en el ViewPort, tal y como se hicieron anteriormente y son sujetados al ViewPort. Esto forma el mosaico básico para el llenado y el resto del espacio es llenado basado en el TileMode del pincel. Si está fijado, se aplica la transformación del pincel la cual ocurre después del otro mapeado, escalacion, compensación y así sucesivamente. Un VisualBrush es un TileBrush cuyos contenidos están especificados por un Visual. Este Pincel puede ser utilizado para crear patrones complejos o puede ser usado para dibujar copias adicionales de los contenidos de otras partes de la escena. clase pública sellada System.Windows.Media.VisualBrush : TileBrush { Visual Brush ( ) público ; / / inicializa en transparente Visual Brush (Visual v) público ; nuevo Visual Brush Copy ( ) público ; // oculta el TileBrush.Copy ( ) / / Visual - El default es nuil (Pincel transparente) Visual Visual público { obtener; ajustar; } El ImageBrush es un TileBrush que tiene contenidos especificados por un ImageData. Este Pincel puede ser utilizado para llenar un espacio con una imagen. clase pública sellada System.Windows.Media.lmageBrush : TileBrush { ImageBrush ( ) público; / / Inicializa en contenido transparente / / Ajusta la imagen, ajusta el ViewBox a (0, 0, Ancho, Alto) // y el Stretch a Fill lmageBrush(lmageData image) público ; nuevo ImageBrush Copy ( ) público ; ?? oculta el TileBrush.Copy ( ) / / El default es nuil ImageData ImageData público { obtener; ajustar; } / / El default es cierto / / Si esto es cierto, la propiedad del ViewBox será invalidada / / y ajustada efectivamente al tamaño original de la Imagen bool SizeViewBoxToContent público { obtener; ajustar; } } El VideoBrush es un TileBrush que tiene los contenidos especificados por un VideoData. Este Pincel puede ser utilizado para llenar un espacio con un Video. clase pública sellada System.Windows.Media.VideoBmsh : TileBrush { VideoBrush () público ; // Inicializa en contenido transparente // Ajusta la imagen, ajusta el ViewBox a (0, 0, Ancho, Alto) y el // Stretchen Fill VideoBrush (VideoData video) público ; nuevo VideoBrush Copy ( ) público ; / / oculta el TileBrush. Copy ( ) / / El default es nuil VideoData VideoData público { obtener; ajustar; } / / El default es cierto / / Si este es cierto, la propiedad del ViewBox será invalidada / / y se ajustará efectivamente al tamaño original del Video bool SizeViewBoxToContent público { obtener; ajustar; } } El NineGridBrush es un Brush el cual siempre llena la caja de límites del objeto con su imagen de contenido y la proyección de la imagen no se lleva a cabo únicamente por medio de una escala visual. La fuente Image es dividida en nueve rectángulos por cuatro límites (de aquí el nombre de NineGrid). Los contenidos de la imagen de cada uno de estas nueve regiones son escaladas en 0, 1 ó 2 dimensiones hasta que llenan el cuadro del límite del objeto. Las dimensiones en las cuales es escalada cada sección se pueden ver en este diagrama: la figura 17 representa el concepto de un NineGrid, siendo ampliado de una primera instancia 1702 a una segunda instancia 1704, mostrando cuatro tipos las nueve rejillas las cuales son definidas por los límites superior, izquierdo, inferior y derecho. Las flechas en cada cuadro del regulador muestran la dimensión en la cual esos contenidos serán proyectados para cubrir el tamaño del ViewPort. Además, de las regiones de la nueve rejillas ilustradas anteriormente, existe una "décima" rejilla opcional. Ésta toma la forma de una imagen adicional la cual es entrada en el ViewPort y la cual no es escalada. Esto se puede utilizar para colocar una forma de centro de un botón, etc. Esta "décima rejilla" es denominada un pictograma, y es expuesta por una propiedad GlyphlmageData: 5 clase pública sellada System.Windows.Media.NineGridBrush : Brush { NineGridBrush(lmageData imageData, int LeftBorder, Q ¡nt RightBorder, int TopBorder, ¡nt BottomBorder) público ; NineGridBrush(lmageData imageData, int LeftBorder, int RightBorder, int TopBorder, int BottomBorder, ImageData glyphlmage) público ; nuevo NineGridBrush Copy ( ) público ; / / oculta el Brush.Copy ( ) '° // El default es nuil ImageData ImageData público { obtener; ajustar; } // El default es 0 int LeftBorder público { obtener; ajustar; } // El default es O int RightBorder público { obtener; ajustar; } // El default es 0 int TopBorder público { obtener; ajustar; } // El default es 0 int BottomBorder público { obtener; ajustar; } / / El default es nuil ImageData GlyphlmageData público { obtener Observar que los elementos del borde cuentan desde la orilla de la imagen en pixeles de la imagen. El Pen es un objeto que toma un Brush u otros parámetros que describen la forma cómo trazar un espacio/Geometría. Conceptualmente, una Pen describe la forma para crear un área de trazos de una Geometry. Una región nueva es creada, la cual está basada en las orillas de la Geometry, el Grueso de la Pluma, el PenLineJoin, PenLineCap, y así sucesivamente. Una vez que es creada esta región, es llenada con el Brush. clase pública sellada System.Windows.Media.Pen : Changeable { / / Constructores Pen público ( ) ; Pen(Brush brush, double thickness) público ; nueva Pen Copy( ) público ; / / oculta el Changeable.Copy ( ) / / Propiedades / / El default es DashArrays.Solid (sin guiones) DoubleCollection DashArray público { obtener; ajustar; } // El default es 0 [Animations (DashOffsetAnimations)] double DashOffset público { obtener; ajustar; } DoubleAnimationCollection I DashOffsetAnimations público { obtener; ajustar; } / / El default es Fiat PenLineCap StartLineCap público { obtener; ajustar; } I El default es Fiat PenLineCap EndüneCap público { obtener; ajustar; } // El default es Fiat PenDashCap DashCap público { obtener; ajustar; } // El default es Miter PenLineJoin LineJoin público { obtener; ajustar; } / / El default es 10 double MiterLimit público { obtener; ajustar; } / / El default es nuil Brush Brush público { obtener; ajustar; } / / El default es 1.0 [Animations(ThicknessAnimations) ] double Thickness público { obtener; ajustar; } DoubleAnimationCollection ThicknessAnimations público { obtener; ajustar; } } El Pen Li neCap determi n a l a forma en q ue son d i bujados extremos de una l ínea trazada : System.Windows. edia.PenLineCap enum público { / / Este efectivamente no tiene tapa de línea - la línea es descuadrada / / en el último punto en la línea Plana, / / La línea es tapada por un semi-círculo de un diámetro igual al / / ancho de la línea Redondo, / / El guión es tapado por un triángulo Triángulo, / / La línea es tapada con un cuadrado de lado con un ancho igual al / / ancho de línea, centrado en el punto del extremo cuadrado } El PenDashCap determina la forma en que termina cada guión en una línea trazada o dibujada con guiones: System.Windows.Media.PenDashCap enum público { / / Este efectivamente no tiene tapa de guión - la línea es descuadrada / / en el último punto en la línea Plana, / / El guión es tapado por un semi-círculode de diámetro igual al // ancho de la línea Redondo, / / El guión es tapado por un triángulo Triángulo } El PenLineJoin determina la forma que se unen los dibujos cuando se está trazando una línea: La clase DashArrays comprende las propiedades estáticas que proporcionan acceso a estilos de guiones comunes bien conocidos: Otro objeto de Pincel representado en la figura 13 es un objeto VisualBrush. Un VisualBrush es un TileBrush cuyos contenidos están especificados por un Visual. Este Pincel puede ser utilizado para crear patrones complejos, o puede ser usado para dibujar copias adicionales de los contenidos de otras partes de la escena. clase pública sellada System.Windows.Media.VisualBrush : TileBrush { Visual Brush ( ) público; / / inicializa en transparente VisualBrush (Visual v) público ; nuevo VisualBrush Copy ( ) público; / / oculta el TileBrush.Copy ( ) / / Visual - El default es nuil (Pincel transparente) Visual Visual público { obtener; ajustar; } Conceptualmente, el VisualBrush proporciona un medio para tener dibujado un visual de un modo en que se forman mosaicos repetidos como un llenado. Éste es representado en la figura 12 por un pincel visual al que hace referencia un visual (y cualesquiera visuales descendentes) que específica una sola forma circular 1220, llenando esa forma circular un rectángulo 1222, por lo tanto, el objeto VisualBrush puede hacer referencia a un visual para definir la forma en que va a ser conducido el pincel, el cual introduce un tipo de uso múltiple para los visuales. De esta manera, un programa puede utilizar un "meta-archivo" de gráficos arbitrario para llenar un área por medio de un pincel o una pluma. Como éste se encuentra en una forma comprimida para el almacenamiento y utilizando gráficos arbitrarios, sirve como un recurso de gráficos. En una implementación, el contenido del VisualBrush no tiene límites intrínsecos y describe de manera efectiva un plano infinito. Estos contenidos existen en su propio espacio de coordenadas y los espacios los cuales están siendo llenados por el VisualBrush es el espacio local de coordenadas en el momento de la aplicación. El espacio de contenido es mapeado en un espacio local basado en las propiedades del ViewBox, ViewPort, Alignments y Stretch. El ViewBox es especificado en el espacio de contenido y este rectángulo es mapeado en un ViewPort (tal y como se especificó por medio de las propiedades de Origen y Tamaño) en un rectángulo. El ViewPort define la localización en donde serán dibujados finalmente los contenidos, creando un mosaico básico para este Pincel. Si el valor de las DestinationUnits es UserSpaceOnUse, las propiedades de Origen y Tamaño son consideradas como que son un espacio local en el momento de la aplicación. Si en vez de ello el valor del DestinationU nits es ObjectBoundingBox, entonces el Origen y el Tamaño son considerados como que están en el espacio de la coordenada en donde 0,0 es la esquina superior/izquierda del cuadro de límites del objeto que está siendo pintado y 1,1 es la esquina inferior/derecha del mismo cuadro. Por ejemplo, considerar un RectangleGeometry que está siendo llenado el cual es dibujado desde 100, 100 a 200, 200. En dicho ejemplo, si las DestinationUnits son UserSpaceOnUse, un Origen de 100, 100 y un Tamaño de 100, 100 describirían el área de contenido total. Si las DestinationUnits son ObjectBoundingBox, un Origen de 0,0, y un Tamaño de 1,1 describiría el área total del contenido. Si el Tamaño está vacío, este Pincel se queda sin producir. El ViewBox es especificado en el espacio de contenido.

Este rectángulo es transformado para que se encaje dentro de un ViewPort, tal y como es determinado por las propiedades de Alignment y la propiedad Stretch. Si la propiedad Stretch es ninguna, entonces no se aplica escalación a los contenidos. Si la propiedad Stretch es Fill entonces el ViewBox es escalado independientemente en ambas X e Y para que sean del mismo tamaño que el ViewPort. Si el Stretch es Uniform o UniformToFill, la lógica es similar, pero las dimensiones X e Y son escaladas de manera uniforme, conservando la proporción de aspecto de los contenidos. Si el Stretch es Uniform, el ViewBox es escalado para que tenga la misma dimensión restringida igual al tamaño del ViewPort. Si el Stretch es UniformToFill, el ViewBox es escalado para que tenga una dimensión menos restringida igual al tamaño del ViewPort. En otras palabras, tanto el Uniform como el UniformToFill conservan la proporción de aspecto, pero el Uniform asegura que el ViewBox completo se encuentra dentro del ViewPort (dejando potencialmente porciones del ViewPort sin cubrir por el ViewBox) y el UniformToFill asegura que el ViewPort completo es llenado por el ViewBox (ocasionando potencialmente porciones del ViewBox para que se encuentren fuera del ViewPort). Si el ViewBox está vacío, entonces no se aplicará Stretch. Observar que la alineación todavía ocurrirá, y colocará el ViewBox del "punto". La figura 18 proporciona representaciones de un solo mosaico de gráficos 1800presentados con diferentes ajustes de proyección, incluyendo un mosaico 1800 cuando la proyección está ajustada a "ninguno". El mosaico 1802 es una representación de cuando la proyección está ajustada en "Uniform", el mosaico 1804 cuando la proyección está ajustada en "UniformToFill", y el mosaico 1806 cuando la proyección está ajustada en "Fill". Una vez que es determinado el ViewPort (basado en DestinationUnits) y el tamaño del ViewBox es determinado (basado en el Stretch), el ViewBox necesita ser colocado dentro del ViewPort. Si el ViewBox es del mismo tamaño que el ViewPort (si el Stretch es Fill, o si solamente ocurre con uno de los otros tres valores Stretch), entonces el ViewBox es colocado en el Origen como para que sea idéntico al ViewPort. De otro modo, se consideran el HorizontalAIignment y el VerticalAlignment. Basado en estas propiedades, el ViewBox es alineado en ambas direcciones X e Y. Si el HorizontalAIignment es Izquierdo, entonces la orilla Izquierda del ViewBox será colocada en la orilla izquierda del ViewPort. Si es en el Centro, entonces el centro del ViewBox será colocado en el centro del ViewPort, y si es a la Derecha, entonces la orilla Derecha se cubrirá. Este proceso se repite para la dimensión Y. Si el ViewBox es (0,0,0,0), se considera no fijado, por lo que se consideran las ContentUnits. Si las ContentUnits son UserSpaceOnUse, no ocurre escalacion o compensación y los contenidos son dibujados dentro del ViewPort sin transformación. Si las ContentUnits son ObjectBoundingBox, entonces, el origen del contenido es alineado con el ViewPort Origin y el contenido es escalado por el ancho y la altura del cuadro de límite del objeto. Cuando se llena un espacio con el VisualBrush, el contenido es mapeado dentro del ViewPort como se indicó anteriormente y es sujetado al ViewPort. Esto forma el mosaico básico para llenar y el resto del espacio es llenado basado en el TileMode del Brush. Finalmente, si está fijado, se aplica la transformación del Brush - la cual ocurre después de todos los otros mapeados, escalación, compensación, etc. La enumeración TileMode es utilizada para describir si y en la forma en que es llenado un espacio por su Brush. Un Brush el cual puede ser en forma de mosaico o que tiene un rectángulo de mosaico definido y este mosaico tiene una localización básica dentro del espacio que está siendo llenado. El resto del espacio es llenado basado en el valor TileMode. La figura 19 proporciona la representación de gráficos de ejemplo con diferentes ajustes del TileMode, incluyendo "None", 1900, "Tile" 1092, "FlipX" 1904, "FlipY" 1906 y "FlipXY" 1908. El mosaico que se encuentra a la izquierda de la parte superior en los diferentes gráficos de ejemplo comprende el mosaico básico. La figura 20 representa un VisualBrush Grid que es definido para los mosaicos en el VisualBrush. El primer círculo es un regulador simple y el segundo tiene una Transformación con un Salto en la dirección x de 47. La figura 21 muestra éste siendo llenado con una imagen. Regresando a la figura 13, el pincel de imagen se deriva del pincel de mosaico y por lo tanto, puede ser formado en un mosaico. El NineGridBrush es muy similar al ImageBrush excepto que la imagen es combada basada en el tamaño. En esencia, se puede considerar que el NineGridBrush es un tipo de diseño del Stretch, en el cual ciertas partes de la imagen se estiran mientras que las otras no (por ejemplo, los bordes). Por lo tanto, aunque el Tamaño de la imagen en el ImageBrush ocasionará una escalación simple, el NineGridBrush producirá una escalación no uniforme al tamaño deseado. Las unidades para las áreas no escaladas son las unidades del usuario cuando es aplicado el pincel, lo cual significa que el ContentUnits (si éste existió para el NineGridBrush) sería ajustado al UserUnitsOnUse. La propiedad Transform del Pincel puede ser utilizada de manera efectiva. Observar que los elementos de los límites cuentan desde el extremo de la imagen. Tal y como se describió de manera general anteriormente, el modelo de objetos gráficos de la presente invención incluye un modelo de objeto Transform, el cual incluye los tipos de transformaciones representadas en la jerarquía de la figura 7, bajo una clase básica Transform. Estos tipos diferentes de componentes que conforman una transformación pueden incluir el TransformList, TranslateTransform, RotateTransform, ScaleTransform, SkewTransform, y MatrixTransform. Las propiedades individuales pueden ser animadas, es decir, un desarrollador de programa puede animar la propiedad de ángulo de un RotateTransform. Las matrices para las computaciones de dos dimensiones se representan como una matriz de 3x3. Para las transformaciones necesarias, solamente se necesitan seis valores, en vez de una matriz 3x3 completa. Estos son denominados y definidos de la manera siguiente. mOO mOl mlO mil m20 m21 Cuando es multiplicada una matriz en un punto, ésta transforma el punto desde el nuevo sistema de coordenadas al sistema de coordenadas anterior: — [X iejoCoordSys yviejoCooidSys Las transformaciones pueden ser anidadas en cualquier nivel. Siempre que es aplicada una nueva transformación es la misma que la transformación posterior a la multiplicación sobre una matriz de transformación actual: " = ?? víejoCoordSy s Y víejoCoordSy s ^ .

La mayor parte de los lugares de la API no toman directamente una matriz, en vez de ello utilizan una clase Transform, la cual soporta la animación.

System.Windows.Media. Matrix estructura pública { / / Construcción y ajuste Matrix( ) pública ; / / defaults para la identidad Matrix ( double mOO, double m01 , double m10, double m11 , double m20, double m21) ; público // Identidad readonly Matrix Identity estática pública ; void Setldentity ( ) espacio público ; bool Isldentity público { obtener; } Matrix operator *(Matrix matrixl , Matrix matrix2 estático público) ; Point operator *(Matrix matrix, Point point) estático público ; / / Estas funciones vuelven a inicializar la matriz actual con / / la matriz de transformación especificada, espacio público SetTranslation(double dx, double dy) ; espacio público SetTrans!ation(Compensación de tamaño) ; espacio público SetRotation(ángulo doble) ; / / grados espacio público SetRotation(double angle, Point center); / / grados espacio público SetRotationRadians(ángulo doble) ; espacio público SetRotationRadians(ángulo doble, Point center) ; espacio público SetScaling(double sx, double sy) ; espacio público SetScaling(double sx, double sy), Point center) ; espacio público SetSkewX(ángulo doble) ; / / grados espacio público SetSkewY(ángulo doble) ; / / grados espacio público SetSkewXRadians(ángulo doble) ; espacio público SetSkewYRadians(ángulo doble) ; / / Estas funciones post-multiplican la matriz actual / / con la transformación especificada espacio público ApplyTranslation(double dx, double dy) ; espacio público ApplyTranslation(Size offApply) ; espacio público ApplyRotation(ángulo doble) ; // grados espacio público ApplyRotation(ángulo doble, Point center) ; / / grados espacio público ApplyRotationRadian(ángulo doble) ; espacio público ApplyRotationRadian(ángulo doble, Point center) ; espacio público ApplyScaling(double sx, double sy); espacio público ApplyScalingídouble sx, double sy, Point center) ; espacio público ApplySkewX(ángulo doble) ; / / grados espacio público ApplySkewY(ángulo doble) ; / / grados espacio público ApplySkewXRadians(ángulo doble) ; espacio público ApplySkewYRadians(ángulo doble) ; espacio público ApplyMatrix(Matrix matrix) ; / / Relleno de Inversión double Determinant público { obtener; } bool Islnvertible público { obtener; } espacio público Invert ( ) ; / / Descarta el ArgumentException ! Islnvertable Matrix Invert (Matrix matrix) estática pública; / / Elementos individuales double MOO público { obtener; ajustan } double M01 público { obtener; ajustar; } double M10 público { obtener; ajustar; } double M11 público { obtener; ajustar; } double M20 público { obtener; ajustar; } double M21 público { obtener; ajustar; } CONCLUSIÓN Como se puede observar por la descripción detallada anterior, se proporciona un sistema, método y modelo de objeto que proporcionan un código de programa con la capacidad para hacer interfase con un gráfico de escena. El sistema, método y modelo de objeto son directos para utilizarlos, todavía poderosos sensibles y extensibles. Aunque la presente invención es susceptible a varias modificaciones y construcciones alternativas, ciertas modalidades ilustradas de la misma se muestran en los dibujos que han sido descritos anteriormente en detalle. Sin embargo, deberá quedar entendido, que no existe la intención de limitar la presente invención a las formas específicas descritas, sino por el contrario, la intención es cubrir todas las modificaciones, construcciones alternativas y equivalentes que se encuentran dentro del espíritu y alcance de la presente invención.

Claims (64)

1. REIVINDICACIONES 1. En un entorno de cómputo, un método el cual comprende recibir una invocación de función por medio de una interfase de un objeto, y el objeto de un modelo de objeto asociado con una escena de gráficos; responder a la invocación de la función ocasionando que los datos del gráfico de escena sean modificados.
2. 2. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos del gráfico de escena sean modificados comprende ocasionar la inicialización de un nuevo ejemplo de una clase visual.
3. 3. El método tal y como se describe en la reivindicación 2, caracterizado porque ocasionar que los datos del gráfico de escena sean modificados comprende invocar un código para asociar una transformación con un objeto visual en el gráfico de escena.
4. 4. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos en una estructura de datos de gráficos de escena sean modificados comprende invocar el código para colocar un visual de dibujo en el gráfico de escena.
5. 5. El método tal y como se describe en la reivindicación 4, el cual comprende además, ocasionar que se regrese un contexto de dibujo, proporcionando el contexto de dibujo un mecanismo para presentarlo en un visual de dibujo.
6. 6. El método tal y como se describe en la reivindicación 2, caracterizado porque ocasionar que los datos del gráfico de escena sean modificados comprende invocar un código para asociar datos de pincel con un objeto visual en el gráfico de escena.
7. 7. El método tal y como se describe en la reivindicación 6, caracterizado porque los datos de pincel comprenden recibir datos que corresponden a un color sólido.
8. 8. El método tal y como se describe en la reivindicación 6, caracterizado porque recibir los datos de pincel comprende recibir datos que corresponden a un pincel de gradiente lineal y una colección de tope que comprende por lo menos un tope.
9. 9. El método tal y como se describe en la reivindicación 6, caracterizado porque recibir los datos de pincel comprende recibir datos que corresponden a un pincel de gradiente radial.
10. 10. El método tal y como se describe en la reivindicación 6, caracterizado porque recibir los datos del pincel comprende recibir datos que corresponden a una imagen.
11. 11. El método tal y como se describe en la reivindicación 10, el cual comprende además, recibir una invocación de función por medio de una interfase que corresponde a un efecto de imagen para aplicarlo a la imagen.
12. 12. El método tal y como se describe en la reivindicación 1, el cual comprende además, recibir datos de pluma en asociación con la invocación de la función, en donde ocasionar que los datos de la estructura de datos de gráficos de escena sean modificados comprende invocar una función de pluma que define un subrayado de una forma.
13. 13. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos gráficos de escena sean modificados comprende invocar el código para representar una elipse en la estructura de datos de gráficos de escena.
14. 14. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos de gráficos de escena sean modificados comprende invocar un código para representar un rectángulo en la estructura de datos de gráficos de escena.
15. 15. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos del gráfico de escena sean modificados comprende invocar un código para representar una trayectoria de la estructura de datos del gráfico de escena.
16. 16. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos del gráfico de escena sean modificados comprende invocar el código para representar una línea en la estructura de datos del gráfico de escena.
17. 17. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos de gráficos de escena sean modificados comprende invocar un código relacionado con una prueba de recuperación de un visual en la estructura de datos del gráfico de escena.
18. 18. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos de gráfico de escena sean modificados comprende invocar un código para transformar las coordenadas de un visual en la estructura de datos del gráfico de escena.
19. 19. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos en una estructura de datos de gráficos de escena sean modificados comprende invocar un código para calcular un cuadro de limite de un visual en la estructura de datos del gráfico de escena.
20. 20. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de una estructura de datos de gráfico de escena sean modificados comprende invocar un código para colocar un objeto visual en la estructura de datos del gráfico de escena.
21. 21. El método tal y como se describe en la reivindicación 1, el cual comprende además invocar un administrador visual para presentar un árbol de por lo menos un objeto visual a un objetivo de presentación.
22. 22. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos en una estructura de datos de gráfico de escena sean modificados comprende invocar un código para colocar un objeto contenedor en la estructura de datos del gráfico de escena, estando configurado el objeto contenedor para contener por lo menos un objeto visual.
23. 23. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de la estructura de datos de gráfico de escena sean modificados comprende invocar un código para colocar datos de imagen en la estructura de datos del gráfico de escena.
24. 24. El método tal y como se describe en la reivindicación 23, caracterizado porque ocasionar que los datos de la estructura de datos del gráfico de escena sean modificados comprende invocar un código para colocar un objeto de efecto de imagen dentro de la estructura de datos del gráfico de escena que está asociado con los datos de imagen.
25. 25. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos en una estructura de datos de gráfico de escena sean modificados comprende invocar un código para colocar los datos correspondientes al texto dentro de la estructura de datos del gráfico de escena.
26. 26. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de una estructura de datos de gráficos de escena sean modificados comprende invocar un código para proporcionar un contexto de dibujo en respuesta a la invocación de función.
27. 27. El método tal y como se describe en la reivindicación 26, caracterizado porque la invocación de función corresponde a una visual retenida y además comprende, un recordatorio de que se tiene que regresar el contexto de dibujo de la visual retenida a la estructura de datos del gráfico de escena.
28. 28. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de una estructura de datos de gráfico de escena sean modificados comprende invocar un código para colocar un visual tridimensional dentro de la estructura de datos del gráfico de escena.
29. 29. El método tal y como se describe en la reivindicación 28, caracterizado porque ocasionar que los datos en una estructura de datos de gráfico de escena sean modificados comprende invocar un código para elaborar un mapa de una superficie bidimensional sobre el visual tridimensional.
30. 30. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de una estructura de datos de gráfico de escena sean modificados comprende invocar un código para colocar datos de animación dentro de la estructura de datos del gráfico de escena.
31. 31. El método tal y como se describe en la reivindicación 30, el cual comprende además comunicar una información de línea de tiempo correspondiente a los datos de animación a una máquina de composición.
32. 32. El método tal y como se describe en la reivindicación 31, caracterizado porque la máquina de composición interpola los datos de gráficos basada en la línea de tiempo para animar una salida correspondiente a un objeto en la estructura de datos del gráfico de escena.
33. 33. El método tal y como se describe en la reivindicación 1, caracterizado porque recibir una invocación de función por medio de una interfase comprende recibir una marca y porque ocasionar que los datos de una estructura de datos de gráfico de escena sean modificados comprende analizar la marca dentro de una invocación a una interfase de un objeto.
34. 34. El método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de una estructura de datos de gráficos de escena sean modificados comprende invocar un código para colocar un objeto correspondiente a datos de audio y/o video dentro de la estructura de datos del gráfico de escena.
35. 35. Ei método tal y como se describe en la reivindicación 1, caracterizado porque ocasionar que los datos de una estructura de datos de gráfico de escena sean modificados comprende invocar un código para cambiar un valor mutable de un objeto en la estructura de datos del gráfico de escena.
36. 36. En un entorno de computación, un sistema el cual comprende: una estructura de datos de gráfico de escena que contiene datos que pueden ser presentados en una salida integrada que puede ser vista; y un modelo de objeto que incluye objetos visuales y otros datos que pueden estar contenidos en la estructura de datos del gráfico de escena.
37. 37. El sistema tal y como se describe en la reivindicación 36, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para colocar un árbol de objetos visuales dentro de una estructura de datos de gráficos de escena.
38. 38. El sistema tal y como se describe en la reivindicación 37, el cual comprende además un administrador visual que cuando es invocado presenta el árbol de objetos visuales a un objetivo de presentación.
39. 39. El sistema tal y como se describe en la reivindicación 37, caracterizado porque el árbol de objetos visuales está contenido en un objeto de colección visual.
40. 40. El sistema tal y como se describe en la reivindicación 26, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para colocar el objeto visual dentro de la estructura de datos del gráfico de escena.
41. 41. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar un pincel con el objeto visual.
42. 42. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar una geometría con el objeto visual.
43. 43. El sistema tal y como se describe en la reivindicación 42, caracterizado porque la geometría comprende por lo menos uno de un conjunto que contiene una geometría de elipse, una geometría de rectángulo, una geometría de línea y una geometría de trayectoria.
44. 44. El sistema tal y como se describe en la reivindicación 40, caracterizado porque lo menos una función de un objeto del modelo de objeto es invocada para asociar una transformación con el objeto visual.
45. 45. El sistema tal y como se describe en la reivindicación 44, caracterizado porque la transformación comprende transformar por medio de la rotación para cambiar un ángulo percibido del objeto visual.
46. 46. El sistema tal y como se describe en la reivindicación 44, caracterizado porque la transformación comprende una transformación de escala para cambiar un tamaño percibido del objeto visual.
47. 47. El sistema tal y como se describe en la reivindicación 44, caracterizado porque la transformación comprende una transformación de traslación para cambiar una posición percibida de un objeto visual.
48. 48. El sistema tal y como se describe en la reivindicación 44, caracterizado porque la transformación comprende una transformación de salto para cambiar un salto percibido del objeto visual.
49. 49. El sistema tal y como se describe en la reivindicación 44, el cual comprende además información de animación asociada con la transformación, y en donde la información de animación ocasiona la transformación de datos asociados con la transformación para cambiar con el transcurso de tiempo animando de este modo la transformación del objeto visual con el transcurso del tiempo.
50. 50. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto de un modelo de objeto es invocada para asociar un color con el objeto visual.
51. 51. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar datos del gradiente con el objeto visual.
52. 52. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar un pincel de mosaico con el objeto visual.
53. 53. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar una imagen con el objeto visual.
54. 54. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar datos tridimensionales con el objeto visual.
55. 55. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar un dibujo que comprende primitivas de dibujo con el objeto visual.
56. 56. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar medios de audio y/o video d con el objeto visual.
57. 57. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar un efecto de imagen con el objeto visual.
58. 58. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar una pluma con el objeto visual para describir el modo en que es subrayada la forma.
59. 59. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para obtener un contexto de dibujo asociado con el objeto visual.
60. 60. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar los datos de la prueba de recuperación con el objeto visual.
61. 61. El sistema tal y como se describe en la reivindicación 40, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para asociar un rectángulo con el objeto visual.
62. 62. El sistema tal y como se describe en la reivindicación 61, caracterizado porque por lo menos una función de un objeto de un modelo de objeto es invocada para describir la forma en que debe de ser extendido el rectángulo fuente para encajar en un rectángulo de destino correspondiente ai objeto visual.
63. 63. El sistema tal y como se describe en la reivindicación 61, caracterizado porque por lo menos una función de un objeto de un modelo de objeto es invocada para describir la forma en que el contenido es colocado verticalmente dentro de un contenedor correspondiente al objeto visual.
64. 64. El sistema tal y como se describe en la reivindicación 61, caracterizado porque por lo menos una función de un objeto del modelo de objeto es invocada para describir la forma el que el contenido es colocado horizontalmente dentro de un contenedor correspondiente al objeto visual.