VCL High-DPI: escalar icones en temps d'execució i evitar el píxelat a TImageList

Qui executa aplicacions VCL en clients moderns Windows es topa, tard o dhora, amb el mateix smptoma: els icones semblen desenfocats a 125%/150%/200%, amb vora grisosa o amb aspecte suavitzat. Justament aquí sorgeix el tema VCL High-DPI Icons en la prctica: no pas perquè High‑DPI sigui nou, sinó perquè els problemes gairebé sempre apareixen en loperativa diria — en servidors Terminal, en canvis destacio del porttil o quan cada monitor té una DPI diferent.

El nucli del problema gairebé mai s que el PNG estigui malms, sin que la pipeline: don prove9 licon (recurs, fitxer, SVG, font), en quina mida sen subministra, com arriba a la TImageList i qui escalar quan i com. A la VCL conflueixen diversos conceptes que cal distingir: DPI-Awareness (si Windows escala laplicacio o si laplicacio sescala a si mateixa), Per-Monitor-DPI (cada monitor pot tenir una DPI diferent) i estratgia dImageList (mantenir diverses resolucions o rasteritzar-les en temps dexecucio).

En aquest article no entrem en debats de disseny dIU, sinó que acostem un enfocament net i operatiu: escalar icones en temps dexecucio de manera que no es converteixin en pur pixeleig, que els canals alpha romanguin intactes i que els canvis de DPI funcionin sense parpelleig ni mides dimatge incorrectes. A ms afegim trappes, consells per a depuracio i una valoracio honesta sobre quan compensa lesforc addicional.

Per què apareix el pixeleig: entendre la cadena descalat a la VCL

La raó ms habitual dicones poc ntids s un down-/upscaling nocircuit correcte en el moment equivocat. Procs clssic en VCL legacy:

• Laplicacio subministra icones només en 16
  16 o 24
  24.
• Windows o la VCL escalen a 20
  20 / 32
  32 / 48
  48.
• El motor descalat fa servir una interpolacio adequada per a fotos, però que en gràfics de píxel difumina les vores.
• Aix shi suma que la transparncia (alpha) es transforma en una lgica de mscara o es converteix diverses vegades.

Resulta especialment dolent quan es produeixen diverses escales consecutives: per exemple, si la ImageList ja subministra un bitmap escalat i Windows torna a escalar a causa de falta de DPI-Awareness o per la DPI del sistema. El resultat: desenfocament per duplicat.

Un segon punt sovint subestimat en projectes s el moment descalat. Amb Per-Monitor-DPI (PMv2, és a dir Per-Monitor-DPI-Awareness v2) la DPI efectiva pot canviar quan una finestra es mou entre monitors o quan un client Remote Desktop ajusta dinàmicament la DPI. Si una TImageList o una memria cau no es reconstrueix correctament, de sobte es veuen icones en la mida errnia o amb la graella incorrecta.

TImageList sota High-DPI: trampes típiques en aplicacions reals

Die TImageList ist historisch für kleine Bitmaps gedacht, mit festen Maßen, Indizes und relativ starrer Speicherlogik. Unter High-DPI ergeben sich daraus praxisnahe Fallen:

1) Fest verdrahtete Width/Height

Viele VCL-Formulare setzen ImageList.Width/Height zur Designzeit und lassen es dabei. Bei 150% möchte Windows aber z. B. aus 16 → 24 machen. Wenn die Liste auf 16 bleibt, wird entweder geclippt oder an anderer Stelle skaliert — beides unschön.

2) PNG-Alpha und Maskenlogik

Je nach Delphi-Version und VCL-Controls landet man schnell in einem Mischbetrieb: PNGs mit Alpha werden intern teils als 32-bit Bitmap gehalten, teils als Mask+Color. Sobald du mehrfach konvertierst (PNG → Bitmap → ImageList → Draw), entstehen graue Halos oder harte Kanten. Der Effekt ist häufig backgroundsensitiv: Auf einer dunklen Toolbar sieht es schlechter aus als auf einem hellen Panel.

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

Einige Controls cachen die Bilddarstellung oder übernehmen ImageList-Handles zu einem Zeitpunkt, an dem die DPI noch nicht final ist. Besonders bei Toolbars, TreeViews/ListViews und OwnerDraw-Szenarien sieht man nach DPI-Wechseln sporadisch falsche Bildgrößen oder leere Icons, bis ein Repaint oder ein RecreateWnd passiert.

4) Terminalserver und Remote-Desktop als Realitätstest

Wenn die App über RDP genutzt wird, sind DPI-Wechsel und Session-Reconnects nicht exotisch. Genau dort bricht dir eine unrobuste ImageList-Strategie um die Ohren: Der Benutzer sieht nach der Reconnect verwaschene Icons oder falsch skalierte Symbolleisten, obwohl lokal alles ok war.

Sauberer Ansatz: Mehrere Auflösungen bereitstellen statt brutales Upscaling

Die wichtigste Entscheidung ist konzeptionell: Willst du Icons zur Laufzeit aus einer einzigen Basisgrafik hochskalieren (z. B. 16 → 32), oder stellst du mehrere native Auflösungen bereit und wählst je nach DPI die passende?

In der Praxis gewinnt fast immer die Mehrfachauflösung. Upscaling ist akzeptabel, wenn die Quelle vektorbasiert ist (SVG, Icon-Font) oder wenn du wirklich nur moderate Faktoren brauchst. Sobald du aus einem kleinen Rasterbild stark hochskalierst, verlierst du Kantenqualität, und das sieht man auf modernen Displays sofort.

In der VCL-Welt sind für diesen Ansatz heute zwei Bausteine relevant:

• TImageCollection: Container für Bilder in mehreren Größen/Varianten.
• TVirtualImageList: erzeugt daraus zur Laufzeit eine ImageList in der aktuell benötigten Größe und reagiert auf DPI-Änderungen.

Das nimmt dir nicht alle Probleme ab, aber es verschiebt das Problem an die richtige Stelle: Du definierst Bildquellen sauber, und die Skalierung/Selektion passiert konsistent.

VCL High-DPI Icons zur Laufzeit skalieren: Wann es sinnvoll ist (und wann nicht)

Es gibt legitime Gründe, Icons zur Laufzeit zu skalieren:

• Du lädst Icons dynamisch (z. B. aus einem Plugin-Ordner, kundenspezifische Branding-Pakete, Konfigurationspakete).
• Du willst eine einheitliche Pipeline für verschiedene Quellen (ICO, PNG, SVG) und möchtest nicht alle Varianten zur Build-Zeit binden.
• Du erzeugst Icons programmgesteuert (Status-Badges, Overlays, zusammengesetzte Symbole).

No té sentit l’escalat en temps d’execució si en realitat només tens icones clàssiques de la barra d’eines d’un conjunt fix. Llavors el camí amb menys manteniment és: subministrar netament diverses resolucions i deixar que la VCL triï.

Si fas escalat en temps d’execució, fes-ho amb regles clares:

• Mai escal·lar de nou un bitmap ja escalat. Sempre parteix d’una font mestre (idealment vectorial o d’alta resolució).
• Caché per mida objectiu i DPI, si no, escalaràs de nou a cada pintada — això consumeix CPU i pot provocar salts.
• Mantenir l’alpha: minimitzar conversions, utilitzar 32-bit RGBA, no rasteritzar el fons.

Arquitectura pragmàtica: pipeline d’icones com a mòdul independent

En aplicacions més grans val la pena no dispersar el tema per tot arreu, sinó construir una petita pipeline. No cal que sigui un framework — més aviat una àrea de responsabilitat clara:

• Font d’icones: D’on provenen els actius mestres (recursos, fitxers, base de dades, API)?
• Rasteritzador/Scaler: Com es genera la mida objectiu des de la font mestra (interpolació, si cal renderització SVG)?
• Caché: clau (Icon-ID, píxels objectiu, DPI, tema) i cicle de vida (invalidar en canvi de DPI, canvi de tema, canvi de paquet).
• Adaptador consumidor: Com arriba el resultat a les estructures VCL (TImageList/TVirtualImageList, OwnerDraw, PaintBox)?

Avantatge: Pots reproduir i depurar errors de DPI de manera reproduïble en un sol punt, en lloc de buscar „on es torna a escalar“ en 40 Forms.

Tractar correctament el canvi de DPI: esdeveniments, rebuild, repaint

Sota Windows els canvis de DPI són un cicle de vida propi. A la VCL, segons la versió i la DPI-Awareness, hi ha diversos esdeveniments/mecanismes, però el principi bàsic és:

• Si la DPI de la finestra canvia, les recursos basades en imatges que han de ser píxel-precises s’han de tornar a preparar.
• Si omples ImageLists dinàmicament, sovint no n’hi ha prou amb un simple Invalidate — necessites un Rebuild de les imatges a la nova mida objectiu.

Un patró vàlid és: en canvi de DPI (p. ex. Form-Scale/Canvi de monitor) invalides el caché d’icones per aquesta DPI i reconstruïx les ImageLists afectades. És important no escalar dins d’esdeveniments de Paint, sinó fer-ho en un bloc d’actualització controlat (Toolbar.BeginUpdate/EndUpdate, ListView-Redraw desactivat i després reactiva). Així evites parpelleigs i estats d’UI a mig fer.

Per què TImageList sovint queda difuminada: interpolació, arrodoniment de DPI, vores

Si entens que el problema no són les DPI, sinó interpolació més arrodoniment, es poden explicar molts efectes:

• Arrodoniment DPI: 125a0% no és un duplicador net. De 16 px passen a 20 px (16 * 1,25). De 24 px passen a 30 px. Són nombres irregulars que compliquen les vores dels píxels.
• Resampling-Filter: Bilinear/Bicubic fa que les vores siguin més suaus. Això està bé per a fotos, però sovint no ho és per a icones.
• Efectes de subpíxel: Windows pot, depenent de la ruta de render, utilitzar Subpixel-Antialiasing o no. Amb icones vols vores controlades — i, si és possible, cap filtrat en múltiples etapes.

Si tens icones raster, és pràctica habitual en molts equips lliurar PNGs específics per a cada mida objectiu (16/20/24/32/40/48). Sembla molt, però sovint suposa menys feina que passar anys depurant per què això es veu estrany en aquest monitor.

Depuració: fer reproducible el „pixelmatsch“ en lloc d’arreglar segons la intuïció

Els errors en entorns High-DPI sovint semblen aleatoris. Amb unes quantes comprovacions esdevenen deterministes:

1) Registrar en temps d’execució DPI i mides d’ImageList

Registra a l’inici i en els canvis de DPI: CurrentPPI del formulari, Screen.PixelsPerInch (Atenció: això pot ser el DPI del sistema), així com ImageList.Width/Height de les llistes afectades. Si després d’un canvi de monitor encara veus 16, tot i que esperaves 32, la causa està clara: falta un rebuild o arriba massa tard.

2) Fer visibles les icones ampliades

Un test ràpid és definir temporalment les icones de la barra d’eines a 48 px. Una mala escalabilitat es veu de seguida. Les pipelines correctes es mantenen nítides també a 48 px perquè rasteritzen a partir d’una font adequada.

3) Provar canvis de tema i fons

Els halos a la vora sovint són problemes d’alpha/premultiply. Prova amb fons clars i foscos i sobre àrees amb degradats. Si la vora es veu diferent segons el fons, el tractament de la transparència no és correcte.

4) Remote Desktop / canvi de monitor com a script de prova

Construeix un script de prova curt per a QA: iniciar l’aplicació al monitor A (100a0%), moure la finestra al monitor B (150a0%), tornar, i després reconnectar RDP. Si això és estable, molts problemes dels clients ja estan resolts.

Migració en aplicacions existents: pas a pas en lloc d’un Big Bang

En aplicacions Delphi-VCL creixudes, la lògica d’icones sovint està a molts llocs: menús, barres d’eines, ActionLists, TreeViews, indicadors d’estat. Un refactor massiu comporta risc. Ha funcionat un enfoc gradual:

• Inventari: Quines ImageLists existeixen? Quins controls les utilitzen? Quines mides s’esperen?
• Prioritzar: Primer les àrees més visibles (barra d’eines principal, navegació, menús contextuals).
• Font unificada: Centralitzar els icones (ImageCollection o un loader propi), en lloc de carregar fitxers per formulari.
• Provar canvis de DPI: Des del primer mòdul migrat, executar sistemàticament proves de canvi de DPI.

Important: Si gestiones en paral·lel una pipeline antiga i una nova, documenta regles clares. Altrament sorgeix un paisatge mixt en què alguns icones són nítids i altres semblen visiblement desajustats.

Rendiment i memòria: escalat en temps d’execució sense efectes secundaris

L’escalat costa CPU i memòria. En un programari empresarial això rarament es nota en repòs, però pot rascallar quan arrossegues la finestra a un monitor nou o en l’inici amb moltes Forms. Tres pautes pràctiques:

• Restringir la mida del cache: No mantinguis cada estat intermedi indefinidament. Si només necessites 100% i 150%, emmagatzema a cache només aquestes mides.
• Lazy Build: Rasteritza els icones només quan la pantalla els necessita realment. En menús grans això estalvia temps d’inici.
• Batch-Rebuild: En un canvi de DPI no disparis cada Control per separat. Un rebuild centralitzat evita escalats redundants.

Si treballes amb TVirtualImageList, gran part d’això ja està contemplat com a concepte, però cal igualment vigilar de no aplicar una escalació pròpia addicional per sobre.

Estratègies de fallback: què fer si no estan disponibles totes les mides d’icona?

En la realitat no sempre tens tots els assets en totes les mides. Cal una estratègia de fallback clara per evitar resultats aleatoris:

• Prioritzar el downscale: Millor reduir de 64 px a 32 px que ampliar de 16 px a 32 px.
• Definir nivells: Estableix quines mides objectiu suportes realment (p. ex. 16/20/24/32/40/48) i mapea el DPI de forma coherent sobre aquestes mides.
• Provar la transparència: En els fallbacks cal prestar atenció a l’alpha — és precisament on apareixen halos.

Un error típic és agafar qualsevol mida següent disponible. Això fa que la percepció de la nitidesa variï segons l’icona. És millor tenir un pla de mapeig ferm i documentat.

Quan val la pena l’esforç realment?

Hi ha tres indicadors clars que justifiquen una pipeline d’icones per a High-DPI ben ferma:

• Els teus usuaris treballen amb monitors mixtos (portàtil + extern) o utilitzen molt RDP.
• L’aplicació és duradora i es mantindrà durant anys — la percepció de la UI forma part de l’acceptació.
• Ja tens planificats passos de modernització (augmentar la DPI-awareness, canviar Controls, revisar el layout de la toolbar).

Si l’app només s’executa en un sistema de quiosc fix amb la mateixa resolució, es pot mantenir l’assumpte al mínim: subministrar una mida d’icona adient, establir correctament la DPI-awareness i llest.

Conclusió: High-DPI no és un detall cosmètic, sinó una decisió de rendering

Els icones borrosos en la VCL rarament són un error aïllat; són un indicatiu d’una cadena poc neta entre fonts, escalat i caché. L’enfocament més robust és proporcionar icones en diverses resolucions i servir-les de manera consistent a través d’una pipeline central (p. ex. ImageCollection/VirtualImageList o una capa d’icones pròpia). L’escalat en temps d’execució té sentit quan tens fonts dinàmiques o símbols compostos, però només amb una font mestre, un caché basat en DPI i regles clares de rebuild.

Si tens símptomes concrets (canvi de DPI que trenca icones, halos al marge, mides incorrectes després d’un RDP), val la pena aïllar el problema i tractar-lo com un petit element arquitectònic en lloc d’acumular workarounds per cada form. Si necessites suport en el debugging o en una modernització pas a pas, trobaràs aquí el punt d’entrada adequat: Kontakt zur Net-Base Software GmbH.

Per a aquest tema també són importants Timagelist High Dpi i Delphi Vcl Dpi-Awareness. L’article contextualitza aquests aspectes de manera comprensible i mostra en què cal fixar-se en l’operativa diària.

Parlar d’un projecte o d’una iniciativa de modernització amb Net-Base.