Compatibilidad con búferes de fotogramas bancarios

La mayoría de los aceleradores tienen búferes de fotogramas que se pueden asignar linealmente al espacio de direcciones de LA CPU. Los controladores de visualización de estos dispositivos no tienen que admitir búferes de fotogramas bancarios.

GDI no puede acceder directamente a la memoria bancaria asociada a un búfer de fotogramas bancarios. Por consiguiente, el controlador de pantalla de un dispositivo con dicho búfer de fotogramas debe dividir el búfer de fotogramas en una serie de bancos contiguos y proporcionar un medio para que GDI realice sus operaciones de dibujo en los bancos de búfer de fotogramas adecuados. Es decir, GDI se realiza para escribir datos en un banco del búfer de fotogramas antes de moverse a los bancos posteriores, según sea necesario, para completar la operación de dibujo a través de un mecanismo denominado devoluciones de llamada bancarias.

Los controladores de visualización de ejemplo de Permedia que se incluyen con el Kit de desarrollo de controladores (DDK) proporcionan código de ejemplo para implementar la compatibilidad con el búfer de fotogramas bancarios. El Kit de controladores de Windows (WDK) no contiene los controladores de visualización de ejemplo 3Dlabs Permedia2 (3dlabs.htm) y 3Dlabs Permedia3 (Perm3.htm). Puede obtener estos controladores de ejemplo desde la DDK de Windows Server 2003 SP1, que puede descargar desde la página DDK - Kit de desarrollo de controladores de Windows del sitio web de WDHC.

En la ilustración siguiente se muestra el búfer de fotogramas del acelerador de ejemplo, un búfer de pantalla VGA de 1024 por 768, dividido en varios bancos. Esta figura solo se proporciona con el propósito de la ilustración. El controlador de pantalla no usa específicamente la dirección física A000, pero usa una dirección lógica que el controlador de miniporte pasa a ella.

En este ejemplo, el contenido de la memoria de vídeo se escribe en el acelerador a través de una serie de operaciones de dibujo que abordan bancos contiguos del búfer de fotogramas. En lo que respecta a GDI, cada una de sus operaciones de dibujo parece ser el búfer de fotogramas estándar y no a diferentes bancos del búfer de fotogramas del acelerador. El controlador de dispositivo para el acelerador controla las operaciones bancarias que hacen que GDI se dibuje al búfer de fotogramas del acelerador de forma bancaria.

El búfer de fotogramas es una superficie administrada por el dispositivo cuando un acelerador emplea un búfer de fotogramas bancario, por lo que el controlador de pantalla enlaza las llamadas a función draw. Cuando el controlador de pantalla enlaza una llamada, como dibujar ruta de acceso, ruta de relleno o transferencia de bloques de bits, determina qué bancos del búfer de fotogramas se ven afectados por la función draw a la que se llamó.

Si el controlador decide que GDI realice la función draw, el controlador llama a la función EngXxx adecuada. Sin embargo, antes de realizar la llamada, el controlador de pantalla debe modificar los objetos clip y surface que recibió en la llamada enlazada y pasar estos objetos modificados en la devolución de llamada a GDI. Los objetos clip y surface se modifican para evitar que GDI dibuse más allá de las extensiones del banco. Es decir, si se llama a GDI para dibujar una ruta de acceso que existe parcialmente en el siguiente banco, y si no hay ninguna modificación de los objetos clip y surface, GDI escribirá en la memoria más allá de las extensiones del banco actual. Si GDI intenta extraer fuera de las extensiones del banco, las infracciones de acceso resultantes pueden ser difíciles de rastrear.

En el búfer de fotogramas de ejemplo de la ilustración siguiente se muestra cómo un objeto elíptico dibujado en la pantalla abarca dos bancos del búfer de fotogramas bancarios, BANK_1 y BANK_2.

Para dibujar este objeto, GDI debe dibujar primero la parte superior de la elipse (en BANK_1) en el búfer de fotogramas estándar y, a continuación, dibujar la parte inferior de la elipse en el mismo búfer estándar. A continuación, el controlador de pantalla debe asignar estas dos escrituras sucesivas por GDI para BANK_1 y BANK_2 del búfer de fotogramas bancarios que se van a mostrar, y también para evitar que GDI escriba más allá de los límites de cada banco.

Al realizar el almacenamiento en búfer de fotogramas bancarios, el controlador de pantalla puede determinar los límites del objeto (el tamaño del rectángulo de destino) comprobando los parámetros de la llamada o llamando de nuevo a GDI. Desde los límites del objeto, el controlador puede determinar cuántos bancos abarca el objeto. Para cada banco que toca el rectángulo delimitador, el controlador de pantalla llama de nuevo a la función de dibujo GDI adecuada, cambiando los valores de cada llamada.

El controlador cambia los miembros CLIPOBJ pasados originalmente por GDI para que correspondan a los cambios en los límites del banco. Los valores de examen superior e inferior se vuelven a definir para que GDI no intente sacar más allá de los límites del banco. El administrador del banco toma los datos CLIPOBJ originales obtenidos de GDI y conserva los valores para la restauración posterior. A continuación, cambia los límites para proporcionar nuevos valores de rclBounds.top y rclBounds.bottom que describen la extensión del banco al que se va a dibujar. Durante la banca, GDI debe realizar el recorte en un tamaño que impida dibujar toda la ruta de acceso y sobrescribir los límites del banco actual.

Si el CLIPOBJ original pasado por GDI se definió como NULL o DC_TRIVIAL, el controlador de pantalla pasa un CLIPOBJ sustituto, creado a través de EngCreateClip. Este CLIPOBJ sustituto se modifica para definir una ventana de recorte para que GDI se recorte en las extensiones de un único banco. Si el CLIPOBJ es complejo, como un objeto clip con forma triangular en una elipse como se muestra en la ilustración anterior, el controlador de pantalla modifica el CLIPOBJ complejo con los valores rclBounds.top y rclBounds.bottom para producir un efecto aditivo entre los dos objetos clip. Como resultado, GDI no puede dejar de escribir el final del banco. El controlador también debe restaurar los límites originales de los datos CLIPOBJ obtenidos anteriormente de GDI.

Además de modificar los valores límites, el controlador de pantalla establece la marca OC_BANK_CLIP en el objeto clip para informar a GDI de que se trata de una devolución de llamada bancaria*.*

GDI también debe hacerse para dibujar con referencia al principio del búfer de fotogramas estándar. Cuando se llama para dibujar, GDI simplemente obtiene un puntero a un SURFOBJ, que incluye los miembros pvScan0, lDelta e iBitmapFormat . GDI calcula dónde dibujar en la superficie usando estos valores de la siguiente manera:

start_draw_point = pvScan0 + (y*lDelta) + (x*PixelSize(iBitmapFormat))

donde x e y son coordenadas en las que se va a comenzar el dibujo y start_draw_point es la dirección en la que se va a dibujar la dirección del primer píxel. GDI realiza este cálculo en cada llamada de dibujo y siempre hace referencia al SURFOBJ para pvScan0, que es la dirección lógica para el inicio del búfer de fotogramas estándar.

Por ejemplo, si GDI necesita dibujar todo el contenido de un búfer de fotogramas de 64K de 8 bits por píxel, comenzando en una dirección lógica de pvScan0 = 0x100000, finalizaría la operación de dibujo en 0x10FFFF (0x100000 + (63*1024)+(1023)), donde y es 63, lDelta es 1024 y x es 1023 (la posición del último píxel en la última línea de examen).

La próxima vez que el controlador de pantalla llame a GDI para dibujar esa parte del objeto que se encuentra dentro del siguiente banco del búfer de fotogramas bancarios, GDI interpreta el valor de y como 64. Con un valor de 0x100000 para pvScan0 y 64 para y, GDI intentaría empezar a escribir datos en 0x110000. Sin embargo, 0x110000 está fuera de la extensión 0x10FFFF del búfer de fotogramas 64K y GDI no debe escribirse en ella durante esta operación.

Por lo tanto, cuando el controlador de pantalla solicita a GDI que escriba los datos que se van a aparecer en el segundo y los bancos posteriores del búfer de fotogramas, el controlador debe disminuir el valor de pvScan0 para que GDI calcule un punto de partida al que todavía se hace referencia a la dirección de ejemplo de 0x100000. Continuando en el ejemplo, esto significa disminuir el valor de pvScan0 en un valor de 0x090000 cuando se dibuja en el segundo banco del búfer de fotogramas. Como resultado de este cambio en pvScan0, GDI sigue dibujando con una referencia a la dirección 0x100000. Es decir, 0x090000 + (64*1024) + 0 es igual a 0x100000, donde GDI debe empezar a dibujar para que los datos se asignen al segundo banco del búfer de fotogramas.