VCL High-DPI: escalar iconos en tiempo de ejecución y evitar la pixelación en TImageList

Quien ejecute aplicaciones VCL en clientes modernos Windows, tarde o temprano se topará con el mismo síntoma: los iconos parecen suavizados, deshilachados o adquieren un borde gris a 125%/150%/200%. Aquí es donde el tema Iconos VCL High-DPI se vuelve práctico: no porque High-DPI sea nuevo, sino porque los problemas suelen aparecer en el uso diario — en servidores de terminal, al acoplar/desacoplar un portátil o cuando cada monitor tiene un DPI distinto.

El tema central casi nunca es «el PNG está dañado», sino la canalización: de dónde viene el icono (recurso, archivo, SVG, fuente), en qué tamaño se suministra, cómo acaba en la TImageList y quién escala cuándo y cómo. En la VCL confluyen varios conceptos que conviene distinguir: DPI-Awareness (si Windows o la propia aplicación realiza el escalado), Per-Monitor-DPI (cada monitor puede ser distinto) y ImageList-Strategie (mantener varias resoluciones o rasterizar en tiempo de ejecución).

En este artículo no se trata de debates de diseño de UI, sino de un enfoque limpio y operativo: escalar iconos en tiempo de ejecución, pero de forma que no se conviertan en pixelado, que los canales alpha permanezcan intactos y que los cambios de DPI funcionen sin parpadeos ni tamaños de imagen erróneos. Además se describen trampas, consejos de depuración y una valoración honesta de cuándo merece la pena el esfuerzo adicional.

Por qué aparece el pixelado: entender la cadena de escalado en la VCL

La causa más frecuente de iconos borrosos es un Down-/Upscaling único en el momento equivocado. Flujo clásico en Legacy-VCL:

• La aplicación entrega iconos solo en 16×16 o 24×24.
• Windows o la VCL los escala a 20×20 / 32×32 / 48×48.
• El escalador utiliza una interpolación que está bien para fotos, pero para gráficos de píxeles difumina los bordes.
• Adicionalmente, la transparencia (alpha) se comprime a una lógica de máscara o se convierte varias veces.

Es especialmente problemático cuando se producen varias escalas consecutivas: por ejemplo, cuando la ImageList ya suministra un bitmap escalado y Windows lo vuelve a escalar por ser DPI-unaware o por la DPI del sistema. Resultado: doble suavizado.

Un segundo punto, subestimado en proyectos, es el momento del escalado. Con Per-Monitor-DPI (PMv2, es decir Per-Monitor-DPI-Awareness v2) la DPI efectiva puede cambiar cuando una ventana cambia de monitor o cuando un cliente de escritorio remoto ajusta la DPI dinámicamente. Si entonces una TImageList o una caché no se reconstruyen correctamente, de repente se ven iconos en tamaño incorrecto o con la trama equivocada.

TImageList bajo High-DPI: trampas típicas en aplicaciones reales

La TImageList fue concebida históricamente para bitmaps pequeños, con dimensiones fijas, índices y una lógica de almacenamiento relativamente rígida. En entornos High-DPI esto genera trampas prácticas:

1) Width/Height fijos

Muchos formularios VCL establecen ImageList.Width/Height en tiempo de diseño y lo mantienen así. Con 150% Windows sin embargo suele querer, p. ej., convertir 16 a 24. Si la lista permanece en 16, la imagen se recorta o se escala en otro sitio; ambas opciones son poco elegantes.

2) PNG-Alpha und Maskenlogik

Según la versión de Delphi y los controles VCL, es fácil acabar en un funcionamiento mixto: los PNG con alpha se mantienen internamente a veces como bitmap de 32 bits y otras como Mask+Color. Si conviertes varias veces (PNG → Bitmap → ImageList → Draw) aparecen halos grises o bordes duros. El efecto suele ser sensible al fondo: en una barra de herramientas oscura se ve peor que en un panel claro.

3) DPI-Wechsel zur Laufzeit: Caches, Handles, OwnerDraw

Algunos controles cachean la representación de la imagen o toman los ImageList-Handles en un momento en que la DPI aún no es definitiva. Especialmente en Toolbars, TreeViews/ListViews y escenarios OwnerDraw, tras cambios de DPI se observan ocasionalmente tamaños de imagen incorrectos o iconos vacíos, hasta que ocurre un repaint o un RecreateWnd.

4) Terminalserver und Remote-Desktop als Realitetstest

Si la aplicación se usa vía RDP, los cambios de DPI y las reconexiones de sesión no son excepcionales. Ahí es donde una estrategia de ImageList poco robusta falla: tras la reconexión el usuario ve iconos difuminados o barras de herramientas mal escaladas, aunque localmente todo estuviera correcto.

Enfoque correcto: proporcionar varias resoluciones en lugar de un escalado brutal

La decisión más importante es conceptual: ¿Quieres escalar iconos en tiempo de ejecución a partir de una única imagen base (p. ej. 16 → 32), o proporcionas varias resoluciones nativas y seleccionas la adecuada según la DPI?

En la práctica casi siempre gana la opción de varias resoluciones. El escalado puede ser aceptable si la fuente es vectorial (SVG, Icon-Font) o si realmente solo necesitas factores moderados. Cuando escalas mucho desde una imagen de mapa de bits pequeña pierdes calidad de bordes, y eso se aprecia de inmediato en pantallas modernas.

En el ámbito VCL son relevantes hoy en día dos componentes para este enfoque:

• TImageCollection: contenedor para imágenes en múltiples tamaños/variantes.
• TVirtualImageList: genera a partir de ellas en tiempo de ejecución una ImageList en el tamaño actualmente requerido y responde a cambios de DPI.

Esto no elimina todos los problemas, pero desplaza el reto al lugar correcto: defines las fuentes de imagen de forma ordenada y la selección/escalado ocurre de manera consistente.

Escalar iconos VCL High-DPI en tiempo de ejecución: cuándo tiene sentido (y cuándo no)

Hay razones legítimas para escalar iconos en tiempo de ejecución:

• Cargas iconos de forma dinámica (p. ej. desde una carpeta de plugins, paquetes de branding personalizados, paquetes de configuración).
• Quieres una canalización unificada para distintas fuentes (ICO, PNG, SVG) y no deseas vincular todas las variantes en tiempo de compilación.
• Generas iconos por programación (Status-Badges, Overlays, símbolos compuestos).

No tiene sentido el escalado en tiempo de ejecución si en realidad solo trabajas con iconos clásicos de barra de herramientas de un conjunto fijo. En ese caso, la vía de menor mantenimiento es: entregar varias resoluciones de forma limpia y dejar que la VCL elija.

Si haces escalado en tiempo de ejecución, hazlo con reglas claras:

• Nunca volver a escalar desde un bitmap ya escalado. Parte siempre de una fuente maestra (idealmente basada en vectores o de alta resolución).
• Cache por tamaño objetivo y DPI, de lo contrario estarás escalando en cada Paint — eso consume CPU y puede provocar tirones.
• Conservar el canal alfa: minimizar conversiones, usar 32-bit RGBA, no rasterizar el fondo.

Arquitectura pragmática: canalización de iconos como componente independiente

En aplicaciones más grandes merece la pena no dispersar el tema por todas partes, sino construir una pequeña canalización. No tiene que ser un framework — más bien un ámbito de responsabilidad claro:

• Fuente de iconos: ¿De dónde provienen los assets maestros (recursos, archivos, base de datos, API)?
• Rasterizador/Escalar: ¿Cómo se genera desde la fuente maestra la(s) imágenes en el tamaño objetivo (interpolación, en su caso renderizado SVG)?
• Cache: clave (Icon-ID, píxeles objetivo, DPI, Theme) y ciclo de vida (invalidar en cambio de DPI, cambio de Theme, cambio de paquete).
• Adaptador consumidor: ¿Cómo llega el resultado a las estructuras de la VCL (TImageList/TVirtualImageList, OwnerDraw, PaintBox)?

Ventaja: puedes depurar bugs relacionados con DPI de forma reproducible en un único lugar, en lugar de buscarlos en 40 formularios preguntándote dónde se escala otra vez.

Tratar correctamente el cambio de DPI: eventos, Rebuild, Repaint

En Windows los cambios de DPI son un ciclo de vida propio. En la VCL, según la versión y el nivel de DPI-Awareness, existen varios eventos/mecanismos, pero el principio básico es:

• Si cambian las DPI de la ventana, los recursos basados en imágenes que deben ser pixel-perfect deben ser re-provisionados.
• Si rellenas dinámicamente ImageLists, un mero Invalidate a menudo no basta — necesitas un Rebuild de las imágenes en la nueva tamaño objetivo.

Un patrón práctico es: ante un cambio de DPI (p. ej. Form-Scale/cambio de monitor) invalidas el cache de iconos para esa DPI y reconstruyes las ImageLists afectadas. Es importante no escalar dentro de eventos Paint, sino en un bloque de actualización controlado (Toolbar.BeginUpdate/EndUpdate, ListView-Redraw desactivado y luego reactivado). Así evitas parpadeos y estados intermedios incompletos de la UI.

Por qué TImageList suele quedar borrosa: interpolación, redondeo de DPI, bordes

Una vez que entiendes que el problema no es la DPI en sí, sino la interpolación más el redondeo, se pueden explicar muchos efectos:

• DPI-Rundung: 125a0% no es un duplicador limpio. De 16 px pasan a 20 px (16 * 1,25). De 24 px pasan a 30 px. Son números no enteros que dificultan los bordes de los píxeles.
• Resampling-Filter: Bilinear/Bicubic suaviza los bordes. Eso está ffcr bien para fotos, ffcr a menudo no para iconos.
• Subpixel-Effekte: Windows puede, según la ruta de renderizado, usar o no antialiasing subpixel. En los iconos quieres bordes controlados e4a0b7 y mf6glichst no múltiples etapas de filtrado.

Si tienes iconos rasterizados, en muchos equipos es práctica habitual proporcionar PNGs por tamaño objetivo (16/20/24/32/40/48). Parece mucho, pero a menudo supone menos trabajo que pasar años depurando por qué se ve raro en un determinado monitor.

Debugging: Hacer reproducible el pixelado en lugar de arreglar por corazonadas

Los fallos en High-DPI suelen parecer aleatorios. Con unas pocas comprobaciones se vuelven deterministas:

1) Registrar DPI y tamaño de ImageList en tiempo de ejecución

Registra al arrancar y al cambiar DPI: CurrentPPI del form, Screen.PixelsPerInch (Atención: esto puede ser el DPI del sistema), así como ImageList.Width/Height de las listas afectadas. Si después de cambiar de monitor sigues viendo 16 aunque esperabas 32, la causa está clara: falta el rebuild o llega demasiado tarde.

2) Agrandar los iconos para que sean visibles

Una prueba rápida es establecer temporalmente los iconos de la barra de herramientas a 48 px. Una mala escala salta inmediatamente a la vista. Buenos flujos de procesamiento permanecen nítidos incluso a 48 px porque rasterizan desde una fuente adecuada.

3) Probar cambio de tema y de fondo

Los halos en el borde suelen ser problemas de Alpha/Premultiply. Prueba en modos claro/oscuro y en áreas con degradado. Si el borde se ve diferente según el fondo, el tratamiento de la transparencia es incorrecto.

4) Remote Desktop / Cambio de monitor como script de prueba

Crea un breve script de prueba para la QS: iniciar la app en el monitor A (100a0%), mover la ventana al monitor B (150a0%), volver, luego reconectar RDP. Si eso es estable, muchos problemas de clientes ya estarán resueltos.

Migration in bestehenden Anwendungen: Schrittweise statt Big Bang

En aplicaciones VCL Delphi maduras, la lógica de iconos suele estar en muchos sitios: menús, toolbars, ActionLists, TreeViews, indicadores de estado. Un refactor tipo Big Bang implica riesgo. Ha demostrado ser eficaz un enfoque incremental:

• Inventario: ¿Qué ImageLists existen? ¿Qué controles las usan? ¿Qué tamaños se esperan?
• Priorizar: Primero las áreas más visibles (barra de herramientas principal, navegación, menús contextuales).
• Fuente unificada: Centralizar los iconos (ImageCollection u otro loader propio), en lugar de cargar archivos individuales por formulario.
• Probar cambios de DPI: Desde el primer módulo migrado, ejecutar de forma sistemática pruebas de cambio de DPI.

Importante: Si operas en paralelo una canalización antigua y una nueva, documenta reglas claras. De lo contrario se crea un paisaje mixto en el que algunos iconos son nítidos y otros se ven visiblemente borrosos.

Rendimiento y memoria: escalado en tiempo de ejecución sin efectos secundarios

El escalado consume CPU y memoria. En software empresarial esto rara vez se nota en reposo, pero al mover una ventana a un monitor nuevo o al iniciar con muchos formularios puede causar tirones. Tres pautas prácticas:

• Limitar tamaños de caché: No mantengas cada estado intermedio indefinidamente. Si solo necesitas 100% y 150%, almacena en caché solo esos.
• Construcción perezosa: Rasteriza los iconos solo cuando la pantalla realmente los necesita. En menús grandes esto ahorra tiempo de inicio.
• Rebuild por lotes: Ante un cambio de DPI no dispares la reconstrucción por cada control individualmente. Un rebuild central evita escalados redundantes.

Si trabajas con TVirtualImageList, mucho de esto ya está contemplado como concepto, pero aun así debes asegurarte de no añadir además tu propia capa de escalado.

Estrategias de fallback: ¿Qué hacer cuando no están disponibles todos los tamaños de icono?

En la realidad no siempre dispones de todos los assets en todos los tamaños. Entonces necesitas una estrategia de fallback clara para evitar resultados aleatorios:

• Preferir reducción (downscale): Mejor reducir de 64 px a 32 px que ampliar de 16 px a 32 px.
• Define niveles: Establece qué tamaños objetivo realmente soportas (p. ej. 16/20/24/32/40/48) y mapea el DPI con claridad.
• Probar la transparencia: En los fallbacks presta atención especial al canal alfa — es ahí donde suelen aparecer halos.

Un error típico es tomar cualquier tamaño siguiente disponible. Eso hace que la nitidez percibida varíe según el icono. Mejor tener un plan de mapeo rígido y documentado.

¿Cuándo merece la pena el esfuerzo?

Hay tres indicadores claros de que merece la pena una pipeline de iconos High-DPI bien construida:

• Tus usuarios trabajan con monitores mixtos (portátil + externo) o acceden frecuentemente por RDP.
• La aplicación es duradera y se mantiene durante años — la percepción de la UI forma parte de la aceptación.
• Tienes previstos pasos de modernización (mejorar la compatibilidad con DPI, reemplazar controles, revisar el diseño de la barra de herramientas).

Si la app, en cambio, se ejecuta solo en un sistema kiosco fijo con la misma resolución, se puede mantener el tema al mínimo: suministrar un tamaño de icono adecuado, configurar correctamente la DPI-awareness y listo.

Conclusión: High-DPI no es un detalle cosmético, sino una decisión de renderizado

Los iconos borrosos en la VCL rara vez son un fallo aislado; indican una cadena imprecisa entre fuentes, escalado y caching. El enfoque más robusto es proporcionar iconos en varias resoluciones y entregarlos de forma consistente a través de una pipeline central (p. ej. ImageCollection/VirtualImageList o una propia capa de iconos). El escalado en tiempo de ejecución tiene sentido cuando manejas fuentes dinámicas o símbolos compuestos, pero solo con una fuente maestra, caché basado en DPI y reglas de rebuild claras.

Si tienes síntomas concretos (el cambio de DPI rompe iconos, halos en los bordes, tamaños incorrectos tras RDP), merece la pena aislar el problema y tratarlo como un pequeño bloque arquitectónico, en lugar de acumular soluciones ad hoc por cada formulario. Si necesitas apoyo en la depuración o en una modernización por etapas, encontrarás aquí el punto de partida adecuado: Contacto con Net-Base Software GmbH.

Para este tema también son importantes Timagelist High Dpi y Delphi Vcl Dpi-Awareness. El artículo contextualiza estos aspectos de forma comprensible y muestra qué es relevante en el uso diario.

Discutir un proyecto o un plan de modernización con Net-Base.