Compartir a través de

Comparación de la aceleración de hardware de Direct2D y GDI

  • Artículo

Direct2D y GDI son API de representación 2D en modo inmediato y ambas ofrecen cierto grado de aceleración de hardware. En este tema se exploran las diferencias entre Direct2D y GDI, incluidas las diferencias pasadas y presentes en las características de aceleración de hardware de ambas API.

Este tema tiene las siguientes partes:

Diferencias entre Direct2D y GDI

GDI representa geometrías opacas y con alias, como polígonos, puntos suspensivos y líneas. Representa texto con alias y ClearType, y puede admitir la combinación de transparencia a través de la API AlphaBlend. Sin embargo, su control de transparencia es incoherente y la mayoría de las API de GDI simplemente ignoran el canal alfa. Algunas API de GDI garantizan lo que contendrá el canal alfa después de una operación. Lo más importante es que la representación de GDI no se asigna fácilmente a las operaciones 3D y una GPU moderna se representa de forma más eficaz en la parte 3D de su motor de representación. Por ejemplo, las líneas con alias de Direct2D están diseñadas para implementarse simplemente como dos triángulos representados en la GPU, mientras que GDI usa el algoritmo de dibujo de líneas de Bresenham.

Direct2D representa primitivos opacos, transparentes, con alias y anti-alias. Las interfaces de usuario modernas suelen usar la transparencia y la animación. Direct2D facilita la creación de una interfaz de usuario moderna porque tiene garantías estrictas sobre cómo acepta y representa contenido transparente, y todos sus primitivos se representan mediante la aceleración de hardware. Direct2D no es un superconjunto puro de GDI: primitivas que habrían sido innecesariamente lentas cuando se implementan en una GPU no están presentes en Direct2D. Dado que Direct2D se crea con este énfasis en la aceleración 3D, también es fácil de usar con Direct3D.

Desde Windows NT 4, GDI se ha ejecutado en modo kernel. La aplicación llama a GDI que, a continuación, llama a su homólogo del modo kernel que pasa los primitivos a su propio modelo de controlador. A continuación, este controlador envía los resultados al controlador de pantalla del modo kernel global.

A partir de Windows 2000, GDI y los controladores GDI se han ejecutado en un espacio independiente en el kernel denominado "espacio de sesión". Se crea un espacio de direcciones de sesión para cada sesión de inicio de sesión y cada instancia de GDI se ejecuta independientemente en este espacio de direcciones del modo kernel distinto. Sin embargo, Direct2D se ejecuta en modo de usuario y pasa comandos de dibujo a través del controlador direct3D en modo de usuario al controlador en modo kernel.

figura 1: direct2d en comparación con gdi

Aceleración de hardware GDI y Direct2D

La diferencia más importante entre la aceleración de hardware direct2D y GDI es la tecnología subyacente que los impulsa. Direct2D está superpuesta en Direct3D y GDI tiene su propio modelo de controlador, la interfaz del controlador de dispositivo GDI (DDI), que corresponde a los primitivos de GDI. El modelo de controlador de Direct3D corresponde a lo que representa el hardware de representación 3D en una GPU. Cuando la DDI de GDI se definió por primera vez, la mayoría del hardware de aceleración de pantalla tenía como destino los primitivos de GDI. Con el tiempo, se ha puesto más énfasis en la aceleración de juegos 3D y menos en la aceleración de aplicaciones. Como consecuencia, la API de BitBlt se aceleró por hardware y la mayoría de las demás operaciones de GDI no eran.

Esto establece la fase de una secuencia de cambios en la forma en que GDI se representa en la pantalla. En la ilustración siguiente se muestra cómo la representación de la pantalla GDI ha cambiado de Windows XP a Windows 7.

figura 2: evolución de la representación de pantalla gdi

También hubo una serie de factores adicionales que provocaron cambios en el modelo de controlador GDI , como se explica a continuación.

Aumento de la complejidad y el tamaño de los controladores de pantalla

Los controladores 3D se han vuelto más complejos con el tiempo. El código más complejo tiende a tener más defectos, lo que resulta beneficioso para que el controlador exista en modo de usuario, donde un error de controlador no puede provocar un reinicio del sistema. Como se puede ver en la ilustración anterior, el controlador de pantalla se divide en un componente de modo de usuario complejo y un componente de modo kernel más sencillo.

Dificultad para sincronizar espacios de direcciones de kernel y sesión globales

En Windows XP, existe un controlador de pantalla en dos espacios de direcciones diferentes: espacio de sesión y espacio de kernel. Las partes del controlador deben responder a eventos como eventos de administración de energía. Debe sincronizarse con el estado del controlador en el espacio de direcciones de sesión. Esta es una tarea difícil y puede provocar defectos cuando los controladores de pantalla intentan tratar con estos espacios de direcciones distintos.

Administración de ventanas compuestas

El Administrador de ventanas de escritorio (DWM), el administrador de ventanas de redacción introducido en Windows 7, representa todas las ventanas en superficies fuera de la pantalla y, a continuación, las compone juntas para que se muestren en pantalla. Esto requiere que GDI pueda representarse en una superficie que Direct3D representará a continuación. Esto planteaba un problema en el modelo de controlador XP, ya que GDI y Direct3D eran pilas de controladores paralelos.

Como resultado, en Windows Vista, el controlador de pantalla DDI de GDI se implementó como controlador de pantalla canónico (CDD) proporcionado por Microsoft que representa el contenido GDI en un mapa de bits de memoria del sistema que se va a componer en la pantalla.

Representación de GDI en Windows 7

El modelo de controlador usado en Windows Vista requería que todas las ventanas de GDI estén respaldadas por una superficie de memoria de vídeo y una superficie de memoria del sistema. Esto dio lugar a que se usara la memoria del sistema para cada ventana GDI.

Por este motivo, GDI se cambió de nuevo en Windows 7. En lugar de representar en una superficie de memoria del sistema, GDI se modificó para representar en un segmento de memoria de apertura. La memoria de apertura se puede actualizar desde la superficie de memoria de vídeo que contiene el contenido de la ventana. GDI puede volver a representarse en la memoria de apertura y el resultado se puede devolver a la superficie de la ventana. Dado que el segmento de memoria de apertura es direccionable por la GPU, la GPU puede acelerar estas actualizaciones en la superficie de memoria de vídeo. Por ejemplo, la representación de texto, BitBlts, AlphaBlend, TransparentBlt y StretchBlt se aceleran en estos casos.

Contraste de la aceleración de Direct2D y GDI en Windows 7

Direct2D y GDI son API de representación en modo inmediato 2D y están aceleradas por hardware. Sin embargo, hay varias diferencias que permanecen en ambas API.

Ubicación de los recursos

GDI mantiene sus recursos, en particular los mapas de bits, en la memoria del sistema de forma predeterminada. Direct2D mantiene sus recursos en memoria de vídeo en el adaptador de pantalla. Cuando GDI necesita actualizar la memoria de vídeo, esto debe realizarse a través del bus, a menos que el recurso ya esté en el segmento de memoria de apertura o si la operación se puede expresar directamente. En cambio, Direct2D simplemente puede traducir sus primitivos a primitivos de Direct3D porque los recursos ya están en memoria de vídeo.

Método de representación

Para mantener la compatibilidad, GDI realiza una gran parte de su representación en la memoria de apertura mediante la CPU. En cambio, Direct2D traduce sus llamadas API a primitivos y operaciones de dibujo de Direct3D. A continuación, el resultado se representa en la GPU. Parte de la representación de GDI se realiza en la GPU cuando la memoria de apertura se copia en la superficie de memoria de vídeo que representa la ventana GDI.

Escalabilidad

Las llamadas de representación de Direct2D son secuencias de comandos independientes a la GPU. Cada fábrica de Direct2D representa un dispositivo Direct3D diferente. GDI usa un flujo de comandos para todas las aplicaciones del sistema. El método de GDI puede dar lugar a una acumulación de sobrecarga de contexto de representación de GPU y CPU.

Location

Direct2D funciona completamente en modo de usuario, incluido el tiempo de ejecución de Direct3D y el controlador Direct3D en modo de usuario. Esto ayuda a evitar bloqueos del sistema causados por defectos de código en el kernel. Sin embargo, GDI tiene la mayor parte de su funcionalidad en el espacio de sesión en modo kernel, con su superficie de API en modo de usuario.

Disponibilidad de la aceleración de hardware

GDI se acelera por hardware en Windows XP y se acelera en Windows 7 cuando se ejecuta el Administrador de ventanas de escritorio y se usa un controlador WDDM 1.1. Direct2D está acelerado por hardware en casi cualquier controlador WDDM y si DWM está en uso o no. En Vista, GDI siempre se representará en la CPU.

Modelo de presentación

Cuando Windows se diseñó por primera vez, no había memoria suficiente para permitir que todas las ventanas se almacenen en su propio mapa de bits. Como resultado, GDI siempre se representa lógicamente directamente en la pantalla, con varias regiones de recorte aplicadas para asegurarse de que una aplicación no se representa fuera de su ventana. En el modelo de Direct2D , una aplicación se representa en un búfer de reserva y el resultado se muestra cuando la aplicación ha terminado de dibujar. Esto permite que Direct2D controle escenarios de animación mucho más fluidos de lo que puede hacer GDI.

Conclusión

El código GDI existente seguirá funcionando bien en Windows 7. Sin embargo, al escribir código de representación de gráficos nuevo, se debe tener en cuenta Direct2D , ya que aprovecha mejor las GPU modernas.