VCL High‑DPI: Skalun tákna í keyrslutíma og forðast óskýrar píxla í TImageList

Sá sem rekur VCL-forrit á nútímalegum Windows-viðskiptavinum rekst fyrr eða síðar á sama einkenni: Icons virðast við 125%/150%/200% óskýr, fransuð eða fá gráan brún. Hér kemur umræðan um VCL High-DPI Icons að gagni: ekki vegna þess að High-DPI sé nýtt, heldur vegna þess að vandamálin koma yfirleitt fyrst fram í daglegum aðstæðum — á Terminalserverum, við skipti á fartölvu í dokk eða þegar mismunandi DPI eru í notkun á mörgum skjám.

Kjarnaefnið er nánast aldrei „PNG-ið er bilað“, heldur gagnstreymið: Hvaðan kemur táknið (Ressource, Datei, SVG, Font), í hvaða Größe er það afhent, hvernig endar það í TImageList og hver skalar hvenær með hvaða aðferð. Í VCL koma nokkur hugtök saman sem þarf aðgreina: DPI-Awareness (hvort Windows skaliar forritið fyrir það eða hvort forritið sjálft skaliar sig), Per-Monitor-DPI (hver skjár má hafa aðra stillingu) og ImageList-Strategie (að hafa fyrirfram mörg Auflösungen eða að rastera í keyrslu).

Í þessum skrifum er ekki ætlunin að fara í UI-design-debattur, heldur að lýsa hreinum, rekstraröruggum aðferðafræði: að skala Icons í keyrslu, en þannig að þau breytist ekki í pixelmött, að Alpha-rásir haldist óbreyttar og að DPI-breytingar virki án blikkandi eða rangra Bildgrößen. Einnig koma upp algengar gildrur, debugging-hint og heiðarleg matning á því hvenær aukakostnaðurinn borgar sig.

Warum Pixelmatsch entsteht: Skalierungskette in der VCL verstehen

Algengasti ástæðan fyrir óskýrri Icons er einangruð niður-/uppskalun á röngum tíma. Klassískur ferill í Legacy-VCL:

• Forritið afhendir Icons aðeins í 1616 eða 2424.
• Windows eða VCL skalar upp í 2020 / 3232 / 4848.
• Skalarinn notar milligreiningu (Interpolation) sem er ásættanleg fyrir ljósmyndir en óæskileg fyrir pixla-grafík þar sem hún óskar kantana.
• Auk þess er gagnsæi (Alpha) troðið inn í maskalógík eða umreiknað margfalt.

Sérstaklega óheppilegt er þegar mörg skalunarstigin gerast í röð: til dæmis þegar ImageList þegar gefur frá sér skalað bitmap og Windows skalar aftur vegna þess að forritið er DPI-unaware eða vegna System-DPI. Niðurstaðan: tvöfaldur mjúkleiki.

Annar, oft vanmetinn þáttur í verkefnum er tímasetning skalunar. Við Per-Monitor-DPI (PMv2, þ.e. Per-Monitor-DPI-Awareness v2) getur skilgreind DPI breyst þegar gluggi skiptir um skjá eða þegar Remote-Desktop-viðskiptavinur stillir DPI dynamískt. Ef þá er TImageList eða cache ekki rétt endurbyggt, birtast tákn fljótt í röngri Größe eða með rangt raster.

TImageList unter High-DPI: typische Fallen in echten Anwendungen

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×16 eher 24×24 machen. Wenn die Liste auf 16×16 bleibt, wird entweder geclippt oder skaliert an anderer Stelle — 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 dunkler Toolbar sieht es schlimmer 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, wo die DPI noch nicht final ist. Besonders bei Toolbars, TreeViews/ListViews und OwnerDraw-Szenarien sieht man nach DPI-Wechseln sporadisch falsche Bildgrößen oder bzw. 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 fliegt dir eine unrobuste ImageList-Strategie um die Ohren: Der Benutzer sieht nach dem 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×16 → 32×32), oder stellst du mehrere native Auflösungen bereit und wählst je nach DPI die passende?

In der Praxis gewinnt fast immer mehrere Auflösungen. Upscaling kann man machen, 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 siehst du 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).

Skaðlegt er að nota skalun í keyrslutíma ef þú ert í raun með eingöngu klassísk tákn fyrir tólbara úr föstu safni. Þá er viðhaldsminnsti kosturinn: afhenda mörg upplausnarmyndskeið hreint og láta VCL velja.

Ef þú framkvæmir skalun í keyrslutíma, þá með skýrum reglum:

• Aldrei breyta stærð úr bitamöppu sem þegar hefur verið skölvuð. Alltaf byggja á master-uppsprettu (kjósið helst vektorbundið eða háupplausnar).
• Cache fyrir markstærð og DPI, annars skalarðu við hvert paint aftur — það kostar CPU og getur valdið stokkleika.
• Varðveita alfa: lágmarka umbreytingar, stilla á 32-bit RGBA, ekki rastergera bakgrunninn.

Pragmatísk arkitektúr: táknapípla sem sjálfstæður hluti

Í stærri forritum borgar sig að dreifa þessu ekki um allan kóðann, heldur byggja litla pípu. Þetta þarf ekki að vera rammasafn — frekar skýr ábyrgðarsvið:

• Tákn-uppspretta: Hvaðan koma master-assets (auðlindir, skrár, gagnagrunnur, API)?
• Rasterizer/Scaler: Hvernig er úr master framleitt í markstærð (interpolering, ef við á SVG-render)?
• Cache: Lykill (Icon-ID, markpixlar, DPI, þema) og líftími (ógilda við DPI-breytingu, þema-breytingu, pakkabreytingu).
• Consumer-Adapter: Hvernig fer niðurstaðan inn í VCL-uppbyggingu (TImageList/TVirtualImageList, OwnerDraw, PaintBox)?

Kosturinn: Þú getur endurtekt og fellt DPI-villur á einum stað í stað þess að leita um 40 Forms að því „hvar er enn verið að skala“.

Meðhöndlun DPI-breytinga rétt: atburðir, Rebuild, Repaint

Undir Windows eru DPI-breytingar eigin líftími. Í VCL eru, eftir útgáfu og DPI-vitund, nokkrir atburðir/meginmekanismar, en grunnreglan helst sú sama:

• Ef DPI gluggans breytist þurfa myndbundnar auðlindir sem eiga að vera pixla-nákvæmar að vera endurútvegaðar.
• Ef þú fyllir ImageLists dynamískt dugar oft ekki einfalt Invalidate — þú þarft eitt Rebuild á myndunum í nýrri markstærð.

Praktískt mynstur er: við DPI-breytingu (t.d. Form-Scale/skipti skjáa) ógildirðu tákn-cache fyrir þá DPI og byggir viðkomandi ImageLists upp aftur. Mikilvægt er að ekki skala í Paint-atburðum, heldur í stjórnaðri uppfærslu (Toolbar.BeginUpdate/EndUpdate, ListView-Redraw slökkt, svo kveikt aftur). Þannig forðastu flökt og hálfkláruð UI-ástand.

Af hverju TImageList verður svona oft óskýr: Interpolering, DPI-námundun, brúnir

Þegar þú skilur að það er ekki DPI sjálft sem er vandamálið, heldur interpolering plús námundun, má útskýra mörg áhrif:

• DPI-námundun: 125% er ekki hreinn tvöfaldi. Úr 16 px verða 20 px (16 * 1,25). Úr 24 px verða 30 px. Þetta eru ójöfnar tölur sem flækja píxelahliðar.
• Resampling-sía: Bilinear/Bicubic gerir jaðar mýkri. Þetta er í lagi fyrir ljósmyndir, en oft ekki fyrir tákn (Icons).
• Subpixel-áhrif: Windows getur, eftir render-slóð, notað Subpixel-Antialiasing eða ekki. Fyrir tákn viltu stýrða jaðar og helst enga mörgfalt síustig.

Ef þú ert með raster-tákn er í mörgum teymum algeng aðferð að afhenda sér PNG fyrir hverja markstærð (16/20/24/32/40/48). Hljómar eins og mikið, en er oft minni vinna en að verja ár í að rekja „af hverju lítur þetta einkennilega út á þessum skjá“.

Villuleit: Gera pixlaóreiðu endurframkvæmanlega í stað þess að laga eftir innsæi

High-DPI-villur virðast oft tilviljanakenndar. Með nokkrum athugunum verða þær endurframkvæmanlegar:

1) DPI und ImageList-Größe zur Laufzeit loggen

Skráðu við upphaf og við DPI-breytingu: CurrentPPI des Forms, Screen.PixelsPerInch (Achtung: das kann System-DPI sein), sowie ImageList.Width/Height der betroffenen Listen. Ef þú sérð enn 16 eftir skjábreytingu þótt þú búist við 32 er orsökin augljós: Rebuild vantar eða kemur of seint.

2) Icons sichtbar vergrößern

Eitt hraðpróf er að stilla Toolbar-Icons tímabundið á 48 px. Slæm skölun kemur þá strax fram. Góðar píplínur haldast skarpar við 48 px, því þær rastera úr viðeigandi uppsprettu.

3) Theme- und Hintergrundwechsel testen

Halo við jaðar eru oft Alpha-/Premultiply-vandamál. Prófaðu á ljósu/dökku og á svæðum með litaskala. Ef jaðarinn lítur öðruvísi út eftir bakgrunni er meðferð gagnsæis röng.

4) Remote Desktop / Monitorwechsel als Testskript

Búðu til stutt prófskrift fyrir QS: ræstu appið á skjá A (100%), flytðu gluggann á skjá B (150%), til baka, síðan endurtengdu RDP. Ef þetta er stöðugt eru mörg viðskiptavinavandamál leyst.

Migration in bestehenden Anwendungen: Schrittweise statt Big Bang

Í þróuðum Delphi-VCL-Anwendungen er táknalógík oft á mörgum stöðum: valmyndir, Toolbars, ActionLists, TreeViews, Statusanzeigen. Stórfelld endurbygging ber áhættu. Sýnt hefur sig að stigvaxin aðferð skilar best:

• Inventur: Welche ImageLists gibt es? Welche Controls nutzen sie? Welche Größen werden erwartet?
• Priorisieren: Zuerst die prominentesten Flächen (Haupttoolbar, Navigation, Kontextmenüs).
• Einheitliche Quelle: Icons zentralisieren (ImageCollection oder eigener Loader), statt pro Form Einzeldateien zu laden.
• DPI-Wechsel testen: Ab dem ersten umgebauten Modul konsequent DPI-Wechsel-Tests fahren.

Mikilvægt: Ef þú rekur samtímis gamla og nýja Pipeline, skráðu skýrar reglur. Annars myndast blandað umhverfi þar sem sum tákn eru skörp en önnur virka sýnilega bbaltab.

Frammistaða og minni: Skölun í keyrslutíma án aukaverkana

Skölun kostar CPU og minni. Í viðskiptahugbúnaði kemur þetta sjaldan fram í tómarúmi, en þegar gluggi er dreginn yfir á nýjan skjá (bbFenster auf neuen Monitor ziehenab) eða við upphaf með mörg Forms getur það hnökkvað. Þrjár hagnýtar leiðarlínur:

• Takmarkaðu cache-stærðir: Ekki halda hverri millistig eilíft. Ef þú þarft aðeins 100% og 150%, geymdu aðeins þau.
• Lazy Build: Rastera/taka fyrir táknin aðeins þegar skjárinn þarfnast þeirra. Í stórum valmyndum sparar það upphafstíma.
• Batch-Rebuild: Við DPI-breytingu ekki kalla á hvert Control fyrir sig. Ein miðlæg endurbygging kemur í veg fyrir endurtekna skölun.

Ef þú vinnur með TVirtualImageList er margt af þessu þegar hluti af hugmyndafræðinni, en þú verður samt að gæta þess að bæta ekki aukinni eigin skölun ofan á.

Fallback-stefnur: Hvað gera þegar ekki allar Icon-Größen liggja fyrir?

Í raunveruleikanum eru ekki alltaf öll assets í öllum stærðum. Þá þarftu skýra fallback-stefnu til að forðast tilviljunarkenndar niðurstöður:

• Prefer Downscale: Frekar að minnka úr 64 px í 32 px en að stækka úr 16 px í 32 px.
• Skilgreindu stig: Ákveddu hvaða markstærðir þú styður í reynd (t.d. 16/20/24/32/40/48) og mappaðu DPI skýrt á þær.
• Prófaðu gagnsæi: Við fallbacks vertu sérstaklega vakandi fyrir alfa-gildi — þar myndast oft halos.

Algengt misræmi er að taka einhvers konar næstu stærð. Þannig breytist skynjuð skerpa eftir tákni. Betra er skýr, skjalfest mapping-plan.

Hvenær borgar sig fyrirhöfnin?

Það eru þrír skýrir vísbendingar um að hreint High-DPI-Icon-Pipeline sé þess virði:

• Notendur þínir vinna með blöndu af skjám (fartölva + ytri) eða nota mikið RDP.
• Forritið er langlíft og verður viðhaldið árum saman, og UI-skynjun er hluti af samþykki.
• Þú stendur annars fyrir uppfærsluverkefnum (DPI-Awareness hækka, Controls skipta út, Toolbar-Layout endurskoða).

Ef forritið hins vegar keyrir eingöngu á föstu kíosk-kerfi með samræmdri upplausn, má halda þessu í lágmarki: skila viðeigandi táknstærð, stilla DPI-Awareness rétt og hafa það gott.

Niðurstaða: High-DPI er ekki aðeins fagurfræðilegt smáatriði, heldur rendering-ákvörðun

Óskýr tákn eru í VCL sjaldan einangruð villa; þau benda á óhreina keðju úr uppsprettum, skölun og skyndiminni. Traustasta leiðin er að bjóða tákn í mörgum upplausnum og afhenda þau í gegnum miðlæga pipeline (t.d. ImageCollection/VirtualImageList eða sértakt táknlag) á samræmdan hátt. Skölun í keyrslutíma er réttmæt þegar þú ert með dynamískar uppsprettur eða samsettar tákn, en aðeins með meginuppsprettu, DPI-byggðu skyndiminni og skýrum endurbyggingarreglum.

Ef þú hefur ákveðin einkenni (DPI-breytingar brjóta tákn, halos við brún, rangar Größen eftir RDP), þá borgar það sig að einangra málið markvisst og meðhöndla það sem lítinn arkitektúr-bita í stað þess að stafla vinnuleiðréttingum fyrir hvert Form. Ef þú þarft Unterstützung við debugging eða stigvaxandi uppfærslu finnur þú hér rétta innganginn: Kontakt zur Net-Base Software GmbH.

Fyrir þetta efni eru einnig Timagelist High Dpi og Delphi Vcl Dpi-Awareness mikilvæg. Greinin setur þessa þætti skiljanlega í samhengi og sýnir hvað skiptir máli í daglegum rekstri.

Ræða verkefni eða endurnýjunaráform með Net-Base.