La combinación de pantallas de alta densidad y aplicaciones clásicas de escritorio ha provocado una avalancha de dudas: por qué se ve borroso el Explorador, cómo activar el modo Hi‑DPI en clientes remotos, qué ajustes tocar en Windows (ajustar DPI, escala y resolución en Windows 11), macOS o Linux y qué deben hacer los desarrolladores para que sus apps escalen y sigan siendo nítidas. Este texto junta en un mismo sitio todo lo necesario para entender y arreglar el problema, desde lo más práctico hasta lo más técnico.
Si vienes buscando cómo lidiar con ventanas desenfocadas, menús minúsculos en un monitor 4K o cómo forzar el escalado correcto en monitores ultrawide 2560×1080 (por ejemplo, cómo elegir resolución manualmente), estás en el lugar indicado. Además de soluciones de usuario, encontrarás qué significa realmente la conciencia de PPP/DPI (per‑monitor, v1 y v2), trucos con manifest y compatibilidad, y pautas concretas para actualizar aplicaciones Win32, Windows Forms o WPF.
Qué es Hi‑DPI y por qué algunas apps se ven borrosas
Las pantallas modernas concentran muchos más píxeles por pulgada (PPP/DPI) que las de hace unos años (de 96 PPP tradicionales a 300 PPP y más). Cuando una app no sabe adaptarse a ese aumento, Windows termina ampliando su interfaz a golpe de mapa de bits, lo que causa el típico efecto borroso al escalar; en Windows 11 incluso existen funciones como Super resolución automática que intentan mejorar la apariencia.
En terminología de Microsoft, una app puede ser no consciente (unaware), consciente del sistema o consciente por monitor (per‑monitor). Cada perfil define si el sistema la escala automáticamente o si debe redibujarse con el nuevo factor de escala. Cuanto mayor es la conciencia de DPI, más nítido será el resultado al mover la ventana entre monitores con escalas distintas.
El caso del Explorador de archivos y apps borrosas del sistema
Muchos usuarios se topan con que en C:\Windows\explorer.exe no aparece la pestaña de Compatibilidad. Explorer es un componente del sistema con tratamiento especial, por eso no verás ahí el panel habitual para “Sobrescribir el comportamiento de escalado de DPI”. Si ves el Explorador o el Panel de control borrosos, el problema suele venir del escalado del sistema (ver cómo cambiar y ajustar la resolución de pantalla) sobre partes de la interfaz no adaptadas.
Para lidiar con apps borrosas en general, Windows 10/11 ofrece opciones como “Permitir que Windows intente corregir aplicaciones para que no estén borrosas” y la anulación de escalado por aplicación. Aunque el Explorador no tenga pestaña de compatibilidad, estas funciones de sistema pueden mejorar el comportamiento global, mientras que para otras aplicaciones sí podrás aplicar la anulación de escalado específica desde sus propiedades.
Modos de conciencia de PPP (DPI awareness) en Windows
En el ecosistema Windows existe una clasificación clara de cómo una app trata el escalado. Entenderla es clave para diagnosticar por qué una ventana se ve nítida en un monitor pero borrosa en otro con un factor de escala distinto.
| Modo | Desde | Cómo ve el PPP | Comportamiento al cambiar PPP |
|---|---|---|---|
| No consciente | N/D | Siempre 96 PPP (100%) | Escalado por mapa de bits (borroso) |
| Consciente del sistema | Windows Vista | Un único PPP: el del monitor principal al iniciar sesión | Se ve nítida solo en ese PPP; si cambias de monitor/escala, Windows amplía mapa de bits (borroso) |
| Per‑monitor (v1) | Windows 8.1 | PPP del monitor donde está principalmente la ventana | HWND de nivel superior recibe WM_DPICHANGED; no hay escalado automático de elementos de UI |
| Per‑monitor v2 | Windows 10 1703 | PPP del monitor activo por ventana | HWND de nivel superior y secundarios reciben notificación; Windows escala área no cliente, diálogos y temas de comctl32 V6 automáticamente |
En per‑monitor v2, la app jamás es escalada por el sistema y debe redimensionar/redibujar su contenido tras WM_DPICHANGED. A cambio, Windows te ahorra trabajo en la no‑cliente (título, barras de desplazamiento), cuadros de diálogo Win32 y ciertos controles con “themes”.
Actualizar una aplicación existente para que sea nítida
El paso mínimo es marcar el proceso como per‑monitor v2 (manifiesto o API) y mover la lógica de layout fuera de la inicialización para ejecutarla también cuando cambia el PPP (WM_DPICHANGED). Al mismo tiempo, hay que revisar suposiciones: deja de cachear eternamente tamaños de fuente y valores dependientes de DPI; recalcula cuando cambie la escala.
Muchas API Win32 no exponen contexto de DPI, por lo que devuelven valores relativos al PPP del sistema. Conviene sustituir llamadas clásicas por las variantes con reconocimiento de DPI, por ejemplo, usar GetSystemMetricsForDpi en lugar de GetSystemMetrics y aplicar funciones como EnableNonClientDpiScaling en WM_NCCREATE.
Modo mixto: reconocimiento de DPI por subproceso
Si tu aplicación es grande o mezcla UI de terceros, puedes adoptar un enfoque por fases: actualiza la ventana principal a per‑monitor y deja ventanas de nivel superior secundarias con el modo original. Para eso existe SetThreadDpiAwarenessContext, que asocia la conciencia de DPI a las ventanas creadas mientras ese contexto está activo.
Ten en cuenta que mezclar modos aumenta la complejidad y existen reglas que Windows no permite romper (por ejemplo, un árbol HWND no puede mezclar conciencias diferentes entre padre e hijo). Si te sales de la norma, el sistema puede forzar un reset del modo DPI del proceso o devolver errores como ERROR_INVALID_STATE al reparentar.
Pruebas imprescindibles y problemas comunes
Prueba a mover ventanas entre monitores con escalas distintas, iniciar en cada monitor, cambiar el factor de escala en caliente y, tras cambiar el monitor principal, cerrar sesión y volver a entrar para detectar cacheos de DPI/sizes. Añade baterías de prueba con Escritorio remoto desde equipos con PPP alto/bajo.
Problemas típicos: no usar el rectángulo sugerido de WM_DPICHANGED; virtualización de valores cuando el subproceso no está en el contexto DPI correcto; y API sin contexto de DPI que obligan a cargar recursos a mano (por ejemplo, sustituir LoadIcon por LoadImage para tamaños adecuados).
SSMS en pantallas 4K: manifest externo y anulación de escalado
SQL Server Management Studio (SSMS) ha ido mejorando, pero durante tiempo el soporte de High DPI fue parcial. Hay dos vías efectivas: usar manifest externo y la anulación de escalado en Compatibilidad.
Manifest externo: crea la clave de registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide con PreferExternalManifest=1 (DWORD). Guarda junto a ssms.exe un archivo ssms.exe.manifest (UTF‑8) para indicar conciencia de DPI. Reinicia y verás iconos y textos más nítidos en UHD 3840×2160.
Anulación de escalado: en el acceso directo de SSMS, pestaña Compatibilidad, marca “Sobrescribir el comportamiento de escalamiento de DPI alto” y elige “Aplicación”. Esto fuerza a SSMS a comportarse como per‑monitor, evitando que Windows lo amplíe por mapa de bits cuando cambia el PPP.
Para auditar la conciencia de DPI de cualquier proceso, Process Explorer (Sysinternals) permite añadir la columna “DPI Awareness”. Verás estados como Desconocido (escala siempre por sistema), Consciente del sistema o per‑monitor. Esta comprobación es muy útil para entender qué esperar de una app concreta.
Virtualización de coordenadas y APIs sin contexto de DPI
Cuando una app o hilo se ejecuta como no consciente o solo consciente del sistema, Windows puede virtualizar valores (p. ej., tamaños de pantalla) para “simular” 96 PPP, lo cual confunde diagnósticos. Asegúrate de que el subproceso opera en el contexto DPI esperado al consultar métricas o crear ventanas, y restaura el contexto tras usar SetThreadDpiAwarenessContext.
Muchas APIs clásicas no incluyen HWND/DPI en su firma. Ejemplos: al cargar iconos, usa LoadImage en vez de LoadIcon; para métricas usa GetSystemMetricsForDpi; para no‑cliente, EnableNonClientDpiScaling. Este tipo de ajustes marca la diferencia entre una UI nítida y otra que el sistema termina escalando por mapa de bits.
Un apunte importante: «hidpi.h» no es Hi‑DPI
Existe una rutina de HID (Human Interface Device) llamada HidP_UsageListDifference cuya cabecera es hidpi.h, lo que da pie a confusiones con “Hi‑DPI”. Esta API nada tiene que ver con escalado de pantalla: sirve para comparar listas de usos HID (botones/inputs) y obtener diferencias entre estados anteriores y actuales.
Su firma devuelve HIDP_STATUS_SUCCESS y utiliza buffers PreviousUsageList y CurrentUsageList, depositando los usos que desaparecen en BreakUsageList y los que aparecen en MakeUsageList. Un cero en una lista se interpreta como delimitador. Por contexto, esto pertenece a HID (teclados, gamepads), no al mundo de las pantallas Hi‑DPI.
Diagnóstico rápido con Process Explorer
Si dudas de cómo escala una app, añade la columna “DPI Awareness” en Process Explorer. Verás estados como Desconocido (el sistema la escala siempre), Consciente del sistema (toma el PPP inicial y no reacciona a cambios), o per‑monitor. Esta comprobación es útil para decidir si necesitas manifest, anulación de escalado o refactor de layout.
Dominar Hi‑DPI significa combinar ajustes de sistema (y opciones de compatibilidad) con buenas prácticas de desarrollo. Con lo aquí explicado, puedes dejar de ver interfaces borrosas, ajustar monitores ultrawide en macOS con resoluciones HiDPI reales, activar el modo de alta densidad en WorkSpaces y, si eres developer, migrar tu app a per‑monitor v2 con un plan claro: responder a WM_DPICHANGED, usar métricas “for DPI” y apoyarte en modo mixto cuando sea necesario.
