La Interfaz de Dispositivo Gráfico (GDI)

 

El GDI es el corazón de las capacidades gráficas de Windows. Todas las funciones de dibujo de líneas y figuras se encuentran en el GDI, además de la gestión de color y funciones de manejo de fuentes. Muchos aspectos del rendimiento de Windows están ligados a la implementación de la GDI y en gran parte del código de la GDI se ha elaborado en lenguaje ensamblador para aumentar sus prestaciones. En el nivel de aplicación Windows proporciona objetos lógicos conocidos como contextos de dispositivos (DC), que describen el estado actual de un objetivo del dibujo particular de la GDI. Por ejemplo, una aplicación obtendrá un DC para una salida de impresora o para operaciones completamente basadas en memoria. Las aplicaciones manejan los DC solo mediante la API Win32. La estructura de datos real DC siempre permanece oculta a la aplicación. En cualquier instante, un DC contiene información sobre objetos tales como la pluma actual (para dibujar líneas), la brocha actual (para rellenar regiones), la selección de color y la posición y dimensiones del objetivo de dibujo lógico.

 

La clave del uso de Windows y de sus aplicaciones en un rango ampliamente dispar de hardware, es la independencia del dispositivo incorporada en la API de Windows. Una aplicación utiliza DC y otros objetos lógicos cuando llama a funciones de la GDI. Nunca escriben datos directamente en un dispositivo de salida. La propia GDI gestiona el proceso de transformación de los datos a un formato adecuado, para que un controlador de dispositivo particular los utilice y lleva a cabo la tarea de colocar una representación de la petición en el dispositivo de salida. Por ejemplo, una aplicación puede llamar al sistema pidiendo que se redibuje su ventana principal. Durante la operación de volver a dibujar, entre muchas otras solicitudes, la GDI puede decir al controlador “en la pantalla, dibuja una línea negra de un píxel de ancho desde la posición (0,48) a la (629,48)”. Si el dispositivo –una impresora matricial de puntos- no puede realizar operaciones como el dibujo de una línea, la GDI partirá la solicitud en operaciones más simples. El controlador de dispositivo recibirá, por ejemplo, una serie de peticiones que le indicará que dibuje puntos individuales. Esta arquitectura libera a las aplicaciones de los problemas de dependencia de los dispositivos y permite que Windows utilice incluso el hardware más sencillo como dispositivo de salida.

 


Esta capacidad de independencia del dispositivo conlleva varios problemas. Además de simplemente elegir y gestionar una representación independiente del dispositivo apropiada a todos los objetos gráficos, se necesita tener una gran cantidad de controladores de dispositivo disponibles, para que la GDI interactúe con el hardware objetivo. Algunos asuntos implican muchos algoritmos complejos y mucho código hábil, como, por ejemplo, el manejo de fuentes complejas a través de un rango de tamaños de punto y luego ser capaz de dibujar la fuente de caracteres de una forma legible en una pantalla 1024 x 768 y en una simple impresora matricial de puntos.

 

En las versiones sucesivas de Windows, las capacidades de la GDI han mejorado considerablemente y la estructura subyacente del sistema se va adaptando a la experiencia ganada en las sucesivas versiones. La gran mayoría de los usuarios en nuestros días, tienen un hardware altamente competitivo: monitores SuperVGA de altísimas resoluciones, impresoras láser o de chorro de tinta, etc. Probablemente el hardware llegará a ser mucho más potente con abundantes dispositivos de más alta resolución y color mejorado. Por esto, es importante obtener el mejor rendimiento posible en unos pocos componentes esenciales, en vez de consumir esfuerzos en cientos de controladores de dispositivos, cada uno con una base instalada limitada. Además ha sido importante presuponer los efectos probables de las tendencias del hardware. Dos de los cambios principales en el subsistema GDI de Windows 95 / 98 reflejan la tendencia del hardware: el motor mapa de bits independiente del dispositivo (DIB) y el subsistema de correspondencia de colores de imágenes (ICM).

 

Windows 3.1 introdujo con éxito en concepto de controlador universal de impresora, un controlador de dispositivo que realiza la mayor parte del trabajo para los otros controladores de dispositivos del sistema. Los llamados minicontroladores de impresora gestionan solo las funciones específicas del hardware de una impresora y confían en el controlador universal para la mayoría de las funciones relacionadas con la impresión. Esta asignación de responsabilidades, permitió a Microsoft invertir con fuerza en un controlador de impresora universal de alto rendimiento y alta calidad y en algún buen ejemplo de minicontrolador de dispositivos, como la LaserJet de Hewlett-Packard. Desde la perspectiva del fabricante de impresoras, el desarrollo del controlador de impresora de Windows pasó a ser un proyecto mucho más simple y menos propenso a errores.

 

Windows 95, y el resto de Windows de consumo, retoman este concepto de diseño con la incorporación del motor DIB y una capacidad de minicontrolador de visualización. El esfuerzo se simplifica (una simple cuenta del código muestra que el controlador de visualización VGA en Windows 3.1 es de unas 41.000 líneas de ensambaldor –solo para un monitor de 16 colores-. En Windows 95, solo es de unas 5.000 lineas para un controlador de 256 colores) considerablemente si el hardware del monitor se equipara a lo que puede hacer el motor DIB, lo que suponía un esfuerzo de desarrollo de implementación muy delicado y complejo. Escribir un minicontrolador de visualización y basarlo en el motor DIB como (según palabras de Microsoft) el controlador de visualización de “buffer de marco plano más rápido del mundo”. El diseño del motor DIB también reconoce el nivel de esfuerzo que los fabricantes de hardware ponen ahora en sus ayudas para el hardware en los sistemas basados en Windows. Si se tiene un acelerador de hardware u otras capacidades, el minicontrolador de visualización puede utilizarlo, en lugar de llamar al motor DIB.

 

Arquitectura GDI.

 

 

GDI 32

 

 

GDI 16

 
                   API de 16 bits                             API de 32 bits                                                                                                                                                                                                                                                                                                                                                                                                Interfaz de

                                                  ajuste                                                        

Adaptador tipográfico TrueType

 

Archivos TrueType (usando archivos proyectados en memoria)

 

Correspondencia de colores de imagines (ICM)

 

Perfiles de color (usando archivos proyectados en memoria)

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


La figura anterior muestra los principales componentes del subsistema GDI. También muestra la descomposición entre los módulos de código de 16 y 32 bits –con una advertencia: el motor DIB es realmente código de 32 bits que se ejecuta con una vista de 16 bits (segmentada) de la memoria del sistema- por lo que, por ejemplo, el código hace uso de instrucciones rápidas del 386 para las operaciones de transferencia de memoria. Hay una cantidad considerable de trucos implicados en la manipulación eficiente de direcciones, pero permiten que las aplicaciones existentes de 16 bits puedan realizar las mejoras de implementación del nuevo motor DIB y que el motor por si mismo, pueda llamar al código de la GDI de 16 bits sin sobrecarga adicional. Si el motor DIB se coloca en el lado de los 32 bits, o bien el modulo GDI de 32 bits tendría que reproducir muchas de las funcionalidades de la GDI o bien el motor GDI incurriría en mucha sobrecarga de ajuste volviendo a llamar al  lado de 16 bits.

 

Antes de mirar con detalle el nuevo motor DIB, y el subsistema ICM, vamos a revisar las mejoras más pequeñas en la GDI de Windows 95 / 98.

 

 

Mejoras en el rendimiento.

 

El rendimiento del subsistema GDI es crítico para la implementación de Windows. Muchas referencias de Windows 3.1 tienden a fijar la atención en el rendimiento del video. Aunque el rendimiento del video, es solo un elemento de todo el conjunto del rendimiento global del sistema, es ciertamente un enorme factor en el rendimiento percibido.

 

Windows 95 / 98 incorpora algunas mejoras incrementales:

 

 

 

Ampliación del límite.

Junto con el movimiento a un subsistema de 32 bits viene el acceso a las zonas de memoria de 32 bits utilizadas por Windows 95 / 98. En Windows 3.1, el subsistema GDI asignaba todos los recursos a partir de un único montón (pila) de 64K –lo que limita significativamente el número total de recursos disponibles en los sistemas que son capaces de ejecutar varias aplicaciones a la vez.

 

En Windows 95 / 98, todavía la GDI mantiene muchos objetos lógicos en un montón limitado de 64K. Las estructuras de datos que describen brochas, plumas y cabeceras de mapa de bits, por ejemplo, permanecen en esta zona de memoria más pequeña. También permanecen ahí las estructuras de contexto de visualización. Sin embargo, ahora la GDI asigna los objetos que pueden consumir realmente espacio en una zona de memoria de 32 bits aparte. Allí se transfieren las regiones GDI, las estructuras de gestión de fuentes y los objetos físicos, lo que reduce considerablemente la presión sobre el montón de 64K. Por ejemplo, la colección de rectángulos que se utiliza para describir una región elíptica puede ocupar 45K. Las consideraciones de rendimiento también influyeron en la decisión de que      objetos sacar de la zona de memoria de 64K. Puesto que tanto el código de 16 como el de 32 tenían que manipular las estructuras, los diseñadores debían tener cuidado para no incurrir en demasiadas cargas del selector cuando se conmuta entre las diferentes áreas del montón.

 

Nuevas estructuras gráficas.

Windows 95 / 98 incorpora casi todas las API gráficas más avanzadas que define Win32. Su inclusión aumenta la conveniencia de Windows para que se utilice como plataforma en aquellas aplicaciones que contienen muchos gráficos. Las nuevas API abarcan:

 

 

Las aplicaciones tales como los paquetes de dibujo y los productos CAD tienen que ocuparse ellas mismas de la presentación muy precisa de los objetos geométricos. Una de las diferencias entre Windows 95 / 98 y Windows NT o Windows 2000 se encuentra en los algoritmos de dibujo que definen los pixels utilizados cuando una aplicación dibuja líneas o rellena figuras. Internamente una aplicación puede dibujar en cualquier parte dentro del espacio de coordenadas de 16 bits (-32.767 a +32767, tanto para la coordenada x como para la y). La GDI puede tener que adaptar a escala esta imagen para permitir que se muestre en una pantalla de 640 x 480 pixels e, independientemente de los aspectos necesarios para realizar la escala, siempre es problemático dibujar una línea diagonal en una pantalla de video. Básicamente, la GDI y el controlador de visualización tienen que calcular entre ellos los pixels que se convierten en negros y los que permanecen blancos. Para la mayoría de los usuarios (y de las aplicaciones), no se aprecia diferencia entre las líneas dibujadas mediante dos algoritmos distintos. Existen diferencias sutiles entre el modo en que dos subsistemas GDI rellenan las figuras en la pantalla. Los algoritmos difieren al determinar que pixels se incluyen o no en el contorno de la figura.

 

TrueType.

El nuevo adaptador tipográfico TrueType está implementado en C. Constituye una adaptación del modulo C++ desarrollado para Windows NT. (El código del sistema operativo Windows NT utiliza extensamente C++. No hay nada de C++ en Windows 95). El nuevo código también implementa una representación matemática mejorada de un tipo de carácter, utilizando aritmética de coma fija de 32 bits, con una parte fraccionaria de 26 bits. Windows 3.1 utiliza una representación de 16 bits con una fracción de 10 bits. Esto conduce a algunos problemas de error en el redondeo (con lo que se reduce la fidelidad en los dispositivos de lata resolución) y dificulta el manejo de los caracteres complejos como los del idioma chino (los caracteres Han).

 

Ahora el adaptador tipográfico utiliza los archivos proyectados en memoria para acceder a los archivos que describen las fuentes (todos aquellos con extensión .TTF) y se han eliminado todos los archivos .FOT asociados.