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.