Desarrollo de aplicaciones de escritorio de alto DPI en Windows

Este contenido está dirigido a desarrolladores que buscan actualizar las aplicaciones de escritorio para controlar los cambios de factor de escala de pantalla (puntos por pulgada o PPP) de forma dinámica, lo que permite que sus aplicaciones estén nítidas en cualquier pantalla en la que se representen.

Para empezar, si va a crear una nueva aplicación de Windows desde cero, se recomienda crear una aplicación de Plataforma universal de Windows (UWP). Las aplicaciones para UWP se escalan de forma automática y dinámica para cada pantalla en la que se ejecutan.

Aplicaciones de escritorio que usan tecnologías de programación de Windows anteriores (programación Win32 sin procesar, Windows Forms, Windows Presentation Framework (WPF), etc.) no pueden gestionar automáticamente el escalado de PPP sin trabajo adicional por parte de los desarrolladores. Sin este tipo de trabajo, las aplicaciones aparecerán borrosas o de tamaño incorrecto en muchos escenarios de uso comunes. En este documento se proporciona contexto e información sobre lo que implica actualizar una aplicación de escritorio para que se represente correctamente.

Factor de escala y PPP de la pantalla

A medida que la tecnología de visualización ha progresado, los fabricantes de paneles de visualización han empaquetado un número creciente de píxeles en cada unidad de espacio físico en sus paneles. Esto ha dado lugar a que los puntos por pulgada (PPP) de los paneles de pantalla modernos sean mucho más altos de lo que históricamente han sido. En el pasado, la mayoría de las pantallas tenían 96 píxeles por pulgada lineal de espacio físico (96 PPP); en 2017, las pantallas con casi 300 PPP o superior están disponibles fácilmente.

La mayoría de los frameworks heredados de interfaz de usuario para escritorio dan por hecho que los DPI de la pantalla no cambiarán durante la vida útil del proceso. Esta suposición ya no se cumple, ya que la densidad de píxeles de la pantalla suele cambiar varias veces a lo largo de la vida útil de un proceso de aplicación. Algunos escenarios comunes en los que cambia el factor de escala o los PPP de la pantalla son los siguientes:

• Configuraciones de varios monitores en las que cada pantalla tiene un factor de escala diferente y la aplicación se mueve de una pantalla a otra (por ejemplo, una pantalla de 4K y una pantalla de 1080p).
• Conexión y desconexión de un portátil de alta densidad de píxeles con un monitor externo de baja densidad de píxeles (o viceversa)
• Conectarse a través de Escritorio remoto desde un portátil o tableta de ppp alto a un dispositivo de ppp bajo (o viceversa)
• Realizar un cambio en la configuración del factor de escala de visualización mientras se ejecutan las aplicaciones

En estos escenarios, las aplicaciones UWP se redibujan automáticamente para el nuevo valor de PPP. De forma predeterminada, y sin trabajo adicional para desarrolladores, las aplicaciones de escritorio no lo hacen. Las aplicaciones de escritorio que no realizan este trabajo adicional para responder a los cambios de DPI pueden aparecer borrosas o con un tamaño incorrecto para el usuario.

Modo de compatibilidad con DPI

Las aplicaciones de escritorio deben indicar a Windows si son compatibles con el escalado de DPI. De forma predeterminada, el sistema considera que las aplicaciones de escritorio no son compatibles con DPI y amplía sus ventanas como mapas de bits. Al establecer uno de los siguientes modos disponibles de reconocimiento de PPP, las aplicaciones pueden indicar explícitamente a Windows cómo desean gestionar el escalado de PPP:

No compatible con DPI

Las aplicaciones que no reconocen los PPP se muestran con un valor fijo de PPP de 96 (100%). Cada vez que estas aplicaciones se ejecutan en una pantalla con una escala de pantalla superior a 96 PPP, Windows ajustará el mapa de bits de la aplicación al tamaño físico esperado. Esto da como resultado que la aplicación aparezca borrosa.

Compatibilidad con DPI del sistema

Las aplicaciones de escritorio adaptadas a los PPP del sistema suelen recibir los PPP del monitor principal conectado en el momento en que el usuario inicia sesión. Durante la inicialización, disponen correctamente su interfaz de usuario (ajustando el tamaño de los controles, eligiendo tamaños de fuente, cargando recursos, etc.) utilizando ese valor de DPI del sistema. Por consiguiente, Windows no aplica escalado por PPP (mediante estiramiento de mapa de bits) a las aplicaciones con reconocimiento de PPP del sistema en pantallas que se muestran con ese único valor de PPP. Cuando la aplicación se mueve a un monitor con un factor de escala diferente, o si el factor de escala del monitor cambia por cualquier otro motivo, Windows escalará las ventanas de la aplicación como mapa de bits, haciendo que aparezcan borrosas. En la práctica, las aplicaciones de escritorio con reconocimiento del PPP del sistema solo se muestran nítidas con un único factor de escala de pantalla y se vuelven borrosas cada vez que cambia el PPP.

Compatibilidad con DPI por monitor y por monitor (V2)

Se recomienda actualizar las aplicaciones de escritorio para que usen el modo de reconocimiento de PPP por monitor, lo que les permite mostrarse correctamente de inmediato cada vez que cambie el PPP. Cuando una aplicación comunica a Windows que quiere ejecutarse en este modo, Windows no escalará la aplicación como un mapa de bits cuando cambie el DPI, sino que enviará WM_DPICHANGED a la ventana de la aplicación. En ese caso, es responsabilidad exclusiva de la aplicación gestionar por sí misma el cambio de tamaño para el nuevo PPP. La mayoría de los marcos de interfaz de usuario usados por las aplicaciones de escritorio (Windows controles comunes (comctl32), Windows Forms, Windows Presentation Framework, etc.) no admiten el escalado automático de DPI, por lo que los desarrolladores deben redimensionar y recolocar el contenido de sus ventanas.

Hay dos versiones de compatibilidad Per-Monitor en las que una aplicación puede registrarse: la versión 1 y la versión 2 (PMv2). El registro de un proceso como en ejecución en el modo de reconocimiento de PMv2 da como resultado:

1. La aplicación recibe una notificación cuando cambia el PPP (tanto las HWND de nivel superior como las HWND secundarias)
2. La aplicación que ve los píxeles sin procesar de cada pantalla
3. La aplicación nunca usa el escalado de mapa de bits de Windows
4. Área no cliente automática (título de ventana, barras de desplazamiento, etc.) Escalado de PPP por Windows
5. Cuadros de diálogo de Win32 (creados con CreateDialog) escalados automáticamente por Windows
6. Recursos de mapa de bits dibujados según el tema en controles estándar (casillas de verificación, fondos de botón, etc.) que se representan automáticamente con el factor de escala de PPP adecuado.

Cuando se ejecuta en modo de reconocimiento de Per-Monitor v2, las aplicaciones se notifican cuando su PPP ha cambiado. Si una aplicación no cambia su tamaño para el nuevo PPP, la interfaz de usuario de la aplicación aparecerá demasiado pequeña o demasiado grande (dependiendo de la diferencia en los valores de PPP anteriores y nuevos).

En la tabla siguiente se muestra cómo se representarán las aplicaciones en diferentes escenarios:

Reconocimiento de PPP por monitor (V1)

El modo de reconocimiento de PPP por monitor V1 (PMv1) se introdujo con Windows 8.1. Este modo de reconocimiento de DPI es muy limitado y solo ofrece las funciones que se indican a continuación. Se recomienda que las aplicaciones de escritorio usen Per-Monitor modo de reconocimiento v2, compatibles con Windows 10 1703 o superior.

La compatibilidad inicial para el reconocimiento por monitor solo ofrecía las aplicaciones siguientes:

1. Se notifica a las ventanas HWND de nivel superior un cambio de DPI y se les proporciona un nuevo tamaño sugerido.
2. Windows no ajustará el mapa de bits a la interfaz de usuario de la aplicación
3. La aplicación ve todas las pantallas en píxeles físicos (consulte virtualización)

En Windows 10 1607 o posterior, las aplicaciones PMv1 también pueden llamar a EnableNonClientDpiScaling durante WM_NCCREATE para solicitar que Windows escale correctamente el área no cliente de la ventana.

Compatibilidad con el escalado DPI por monitor según el marco de interfaz de usuario/la tecnología

La siguiente tabla muestra el nivel de compatibilidad con reconocimiento de PPP por monitor que ofrecen varios marcos de trabajo de interfaz de usuario de Windows en Windows 10, versión 1703:

Actualización de aplicaciones existentes

Para actualizar una aplicación de escritorio existente para controlar el escalado de PPP correctamente, debe actualizarse de forma que, como mínimo, las partes importantes de su interfaz de usuario se actualicen para responder a los cambios de PPP.

La mayoría de las aplicaciones de escritorio se ejecutan en modo de reconocimiento de DPI del sistema. Las aplicaciones adaptadas a los PPP del sistema normalmente se ajustan a los PPP de la pantalla principal (la pantalla en la que se encontraba la bandeja del sistema en el momento en que se inició la sesión de Windows). Cuando cambie el DPI, Windows escalará como mapa de bits la interfaz de usuario de estas aplicaciones, lo que a menudo hará que se vean borrosas. Al actualizar una aplicación con reconocimiento de PPP del sistema para que tenga reconocimiento de PPP por monitor, el código que gestiona la disposición de la interfaz de usuario debe actualizarse para que se ejecute no solo durante la inicialización de la aplicación, sino también cada vez que se reciba una notificación de cambio de PPP (WM_DPICHANGED en el caso de Win32). Normalmente, esto implica volver a consultar las suposiciones del código que la interfaz de usuario solo debe escalarse una vez.

Además, en el caso de la programación Win32, muchas API de Win32 no tienen ningún contexto de PPP ni de pantalla, por lo que solo devolverán valores relativos a los PPP del sistema. Puede ser útil buscar en el código algunas de estas API y sustituirlas por variantes adaptadas a PPP. Algunas API comunes que tienen variantes adaptadas a PPP son:

También es una buena idea buscar tamaños codificados de forma rígida en el código base que suponen un PPP constante y reemplazarlos por código que tenga en cuenta correctamente el escalado de PPP. A continuación se muestra un ejemplo que incorpora todas estas sugerencias:

Ejemplo:

En el ejemplo siguiente se muestra un caso de Win32 simplificado de creación de un HWND secundario. La llamada a CreateWindow presupone que la aplicación se ejecuta a 96 PPP (constante USER_DEFAULT_SCREEN_DPI) y que ni el tamaño ni la posición del botón serán correctos con valores de PPP más altos:

case WM_CREATE: 
{ 
    // Add a button 
    HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me",  
        WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,  
        50,  
        50,  
        100,  
        50,  
        hWnd, (HMENU)NULL, NULL, NULL); 
} 

El código actualizado siguiente muestra:

1. El código de creación de ventanas ajusta según la escala de DPI la posición y el tamaño del HWND secundario para los DPI de su ventana principal
2. Respuesta al cambio de PPP reposicionando y redimensionando el HWND secundario
3. Se han eliminado los tamaños codificados de forma fija y se han sustituido por código que se adapta a los cambios de PPP

#define INITIALX_96DPI 50 
#define INITIALY_96DPI 50 
#define INITIALWIDTH_96DPI 100 
#define INITIALHEIGHT_96DPI 50 

// DPI scale the position and size of the button control 
void UpdateButtonLayoutForDpi(HWND hWnd) 
{ 
    int iDpi = GetDpiForWindow(hWnd); 
    int dpiScaledX = MulDiv(INITIALX_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    int dpiScaledY = MulDiv(INITIALY_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    int dpiScaledWidth = MulDiv(INITIALWIDTH_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    int dpiScaledHeight = MulDiv(INITIALHEIGHT_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    SetWindowPos(hWnd, hWnd, dpiScaledX, dpiScaledY, dpiScaledWidth, dpiScaledHeight, SWP_NOZORDER | SWP_NOACTIVATE); 
} 
 
... 
 
case WM_CREATE: 
{ 
    // Add a button 
    HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me",  
        WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, 
        0, 
        0, 
        0, 
        0, 
        hWnd, (HMENU)NULL, NULL, NULL); 
    if (hWndChild != NULL) 
    { 
        UpdateButtonLayoutForDpi(hWndChild); 
    } 
} 
break; 
 
case WM_DPICHANGED: 
{ 
    // Find the button and resize it 
    HWND hWndButton = FindWindowEx(hWnd, NULL, NULL, NULL); 
    if (hWndButton != NULL) 
    { 
        UpdateButtonLayoutForDpi(hWndButton); 
    } 
} 
break; 

Al actualizar una aplicación adaptada a los PPP del sistema, algunos pasos habituales que se deben seguir son:

1. Marque el proceso como compatible con PPP por monitor (V2) mediante un manifiesto de aplicación (u otro método, según los marcos de interfaz de usuario usados).
2. Hacer que la lógica de diseño de la interfaz de usuario sea reutilizable y sacarla del código de inicialización de la aplicación para poder reutilizarla cuando se produzca un cambio de PPP (WM_DPICHANGED en el caso de la programación de Windows (Win32)).
3. Invalide todo código que dé por hecho que los datos sensibles a los DPI (DPI/fuentes/tamaños/etc.) nunca necesitan actualizarse. Es una práctica muy común almacenar en caché los tamaños de fuente y los valores de PPP al iniciar el proceso. Al actualizar una aplicación para que sea compatible con DPI por monitor, los datos sensibles a los DPI deben volver a evaluarse cada vez que se detecte un nuevo valor de DPI.
4. Cuando se produzca un cambio de PPP, vuelva a cargar (o vuelva a rasterizar) los recursos de mapa de bits para el nuevo PPP o, de forma opcional, estire por mapa de bits los recursos cargados actualmente hasta el tamaño correcto.
5. Busque las API que no sean compatibles con PPP por monitor y reemplácelas por API compatibles con PPP por monitor (si procede). Ejemplo: reemplace GetSystemMetrics por GetSystemMetricsForDpi.
6. Pruebe su aplicación en un sistema con varias pantallas y varios valores de PPP.
7. Para las ventanas de nivel superior de la aplicación que no pueda actualizar para que admitan correctamente el escalado de PPP, use el escalado de PPP en modo mixto (descrito a continuación) para permitir la ampliación de mapa de bits de estas ventanas de nivel superior realizada por el sistema.

Escalado de PPP en modo mixto (escalado de PPP por subproceso)

Al actualizar una aplicación para que admita el reconocimiento de DPI por monitor, a veces puede resultar poco práctico o imposible actualizar todas las ventanas de la aplicación de una sola vez. Esto puede deberse simplemente al tiempo y al esfuerzo necesario para actualizar y probar toda la interfaz de usuario, o porque no posee todo el código de interfaz de usuario que necesita ejecutar (si la aplicación quizá carga la interfaz de usuario de terceros). En estas situaciones, Windows ofrece una forma de adentrarse gradualmente en el mundo de la compatibilidad por monitor al permitirle ejecutar algunas de las ventanas de su aplicación (solo las de nivel superior) en su modo original de reconocimiento de DPI, mientras dedica su tiempo y esfuerzo a actualizar las partes más importantes de su interfaz de usuario.

A continuación se muestra una ilustración de lo que podría tener este aspecto: actualiza la interfaz de usuario de la aplicación principal ("Ventana principal" en la ilustración) para ejecutarse con reconocimiento de PPP por monitor mientras ejecuta otras ventanas en su modo existente ("Ventana secundaria").

Antes de la actualización de aniversario de Windows 10 (1607), el modo de reconocimiento de PPP de un proceso era una propiedad de todo el proceso. A partir de la actualización de aniversario de Windows 10, esta propiedad ahora se puede establecer por ventana de nivel superior. (Las ventanas secundarias deben seguir coincidendo con el tamaño de escala de su elemento primario). Una ventana de nivel superior se define como una ventana sin elemento primario. Normalmente, se trata de una ventana "normal" con botones minimizar, maximizar y cerrar. El escenario para el que está pensado el reconocimiento de PPP de subproceso es aquel en el que Windows escala la interfaz de usuario secundaria (ampliándola como mapa de bits) mientras usted centra su tiempo y sus recursos en actualizar la interfaz de usuario principal.

Para habilitar el conocimiento del valor de PPP del subproceso, llame a SetThreadDpiAwarenessContext antes y después de cualquier llamada de creación de ventanas. La ventana que se crea se asociará con el reconocimiento de PPP que establezca a través de SetThreadDpiAwarenessContext. Use la segunda llamada para restaurar el reconocimiento de PPP del subproceso actual.

Aunque el uso del escalado de PPP por subproceso le permite confiar en que Windows realice parte del escalado de PPP de su aplicación, puede aumentar la complejidad de su aplicación. Es importante que comprenda los inconvenientes de este enfoque y la naturaleza de las complejidades que presenta. Para obtener más información sobre la adaptación a PPP de subproceso, consulte Escalado de PPP en modo mixto y API adaptadas a PPP.

Prueba de los cambios

Después de haber actualizado su aplicación para que admita PPP por monitor, es importante comprobar que la aplicación responde adecuadamente a los cambios de PPP en un entorno con distintas configuraciones de PPP. Algunos detalles específicos para probar incluyen:

1. Mover las ventanas de la aplicación de una pantalla a otra con distintos valores de PPP
2. Iniciar tu aplicación en pantallas con distintos valores de DPI
3. Cambio del factor de escala del monitor mientras se ejecuta la aplicación
4. Cambiar la pantalla que usa como pantalla principal, cerrar sesión de Windows y volver a probar la aplicación después de volver a iniciar sesión. Esto resulta especialmente útil para buscar código que usa tamaños o dimensiones codificados de forma rígida.

Problemas comunes (Win32)

No usar el rectángulo sugerido que se proporciona en WM_DPICHANGED

Cuando Windows envía a la ventana de su aplicación un mensaje WM_DPICHANGED, este mensaje incluye un rectángulo sugerido que debe utilizar para cambiar el tamaño de su ventana. Es fundamental que la aplicación use este rectángulo para cambiar su tamaño, ya que esto hará lo siguiente:

1. Asegúrese de que el cursor del mouse permanecerá en la misma posición relativa en la ventana al arrastrar entre pantallas
2. Evita que la ventana de la aplicación entre en un bucle recursivo de cambios de DPI en el que un cambio de DPI desencadena un cambio de DPI subsiguiente, que a su vez desencadena otro cambio de DPI.

Si tiene requisitos específicos de la aplicación que le impiden usar el rectángulo sugerido que Windows proporciona en el mensaje de WM_DPICHANGED, consulte WM_GETDPISCALEDSIZE. Este mensaje se puede usar para proporcionar Windows un tamaño deseado que quiera usar una vez que se haya producido el cambio de PPP, a la vez que se evitan los problemas descritos anteriormente.

Falta de documentación sobre la virtualización

Cuando un HWND o un proceso se ejecuta como no compatible con PPP o como compatible con PPP del sistema, Windows puede escalarlo mediante mapa de bits. Cuando esto sucede, Windows escala y convierte la información sensible al DPI procedente de determinadas API al espacio de coordenadas del subproceso invocador. Por ejemplo, si un subproceso que no reconoce los PPP consulta el tamaño de la pantalla mientras se ejecuta en una pantalla con PPP altos, Windows virtualizará la respuesta que da a la aplicación como si la pantalla tuviera 96 PPP. Como alternativa, cuando un subproceso con reconocimiento de PPP del sistema interactúa con una pantalla con una PPP distinta de la que se estaba usando cuando se inició la sesión del usuario actual, Windows escalará algunas llamadas a la API al espacio de coordenadas que usaría el HWND si se ejecutara con su factor de escala de PPP original.

Cuando actualizas tu aplicación de escritorio para que admita correctamente la escala de DPI, puede ser difícil saber qué llamadas a la API pueden devolver valores virtualizados según el contexto del subproceso; Microsoft no documenta actualmente esta información de forma suficientemente detallada. Tenga en cuenta que, si llama a una API del sistema desde un contexto de subproceso que no reconoce los PPP o con reconocimiento de PPP del sistema, es posible que el valor devuelto se virtualice. Por ello, asegúrese de que el hilo se ejecuta en el contexto de DPI previsto al interactuar con la pantalla o con ventanas individuales. Al cambiar temporalmente el contexto de PPP de un subproceso mediante SetThreadDpiAwarenessContext, asegúrese de restaurar el contexto anterior cuando haya terminado para evitar provocar un comportamiento incorrecto en otra parte de la aplicación.

Muchas de las API de Windows no disponen de un contexto de PPP

Muchas API de Windows heredadas no incluyen un contexto de PPP o HWND como parte de su interfaz. Como resultado, los desarrolladores suelen tener que realizar trabajo adicional para gestionar el escalado de cualquier información sensible a los PPP, como tamaños, puntos o iconos. Por ejemplo, los desarrolladores que usan LoadIcon deben o bien escalar como mapa de bits los iconos cargados, o bien usar otras API para cargar iconos del tamaño correcto para el DPI adecuado, como LoadImage.

A partir de Windows 11 (compilación 22000), las aplicaciones que crean cursores a partir de datos en memoria pueden usar SetThreadCursorCreationScaling para habilitar el escalado automático de PPP por monitor, similar a los cursores cargados desde los recursos del módulo.

Restablecimiento forzado de la conciencia de DPI de todo el proceso

En general, el modo de percepción de PPP de su proceso no se puede cambiar después de la inicialización del proceso. No obstante, Windows puede cambiar de forma forzada el modo de reconocimiento de DPI de su proceso si intenta incumplir el requisito de que todos los HWND de un árbol de ventanas tengan el mismo modo de reconocimiento de DPI. En todas las versiones de Windows, a partir de Windows 10 1703, no es posible que los distintos HWND de un árbol de HWND se ejecuten en diferentes modos de percepción de PPP. Si intenta crear una relación padre-hijo que infrinja esta regla, la percepción de PPP de todo el proceso puede restablecerse. Esto se puede desencadenar mediante:

1. Una llamada a CreateWindow en la que la ventana padre pasada tiene un modo de reconocimiento de DPI distinto del del subproceso que llama.
2. Una llamada a SetParent en la que las dos ventanas están asociadas a distintos modos de reconocimiento de DPI.

En la tabla siguiente se muestra lo que sucede si intenta infringir esta regla:

Temas relacionados

Referencia de la API High DPI

Escalado de PPP de modo mixto y API adaptadas a PPP.