VCL High-DPI: Icons zur Laufzeit skalieren und Pixelmatsch in TImageList vermeiden

Wer VCL-Anwendungen auf modernen Windows-Clients betreibt, stolpert frfher oder spe4ter fcber dasselbe Symptom: Icons wirken bei 125a0%/150a0%/200a0% wie weichgezeichnet, ausgefranst oder bekommen einen grauen Rand. Genau hier wird das Thema VCL High-DPI Icons praktisch: Nicht, weil High-DPI neu we4re, sondern weil sich die Probleme meist erst im Alltag zeigen e4a0b7 auf Terminalservern, beim Notebook-Dock-Wechsel oder sobald pro Monitor unterschiedliche DPI im Spiel sind.

Das Kernthema ist fast nie bbein PNG ist kaputtab, sondern die Pipeline: Woher kommt das Icon (Ressource, Datei, SVG, Font), in welcher Grf6dfe wird es bereitgestellt, wie landet es in der TImageList und wer skaliert wann wie. In der VCL kommen dazu mehrere Begriffe zusammen, die man auseinanderhalten muss: DPI-Awareness (ob Windows die App oder die App sich selbst skaliert), Per-Monitor-DPI (jeder Monitor darf anders sein) und ImageList-Strategie (mehrere Auflf6sungen vorhalten oder zur Laufzeit rastern).

In diesem Beitrag geht es bewusst nicht um UI-Design-Debatten, sondern um einen sauberen, betriebssicheren Ansatz: Icons zur Laufzeit skalieren, aber so, dass sie nicht zu Pixelmatsch werden, dass Alpha-Kane4le intakt bleiben und dass DPI-Wechsel ohne flackernde oder falsche Bildgrf6dfen funktionieren. Dazu kommen Fallstricke, Debugging-Hinweise und eine ehrliche Einsche4tzung, wann sich der Mehraufwand lohnt.

Warum Pixelmatsch entsteht: Skalierungskette in der VCL verstehen

Der he4ufigste Grund ffcr unscharfe Icons ist ein einmaliges Down-/Upscaling zur falschen Zeit. Klassischer Ablauf in Legacy-VCL:

• Die Anwendung liefert Icons nur in 16d716 oder 24d724.
• Windows oder die VCL skaliert auf 20d720 / 32d732 / 48d748.
• Der Skalierer nutzt eine Interpolation, die ffcr Fotos ok ist, ffcr Pixelgrafik aber Kanten verwischt.
• Zuse4tzlich wird die Transparenz (Alpha) in eine Maskenlogik gepresst oder mehrfach konvertiert.

Besonders fies wird es, wenn mehrere Skalen nacheinander passieren: etwa wenn die ImageList bereits ein skaliertes Bitmap liefert, und Windows wegen DPI-Unaware oder System-DPI nochmal drfcber skaliert. Ergebnis: doppelt weichgezeichnet.

Ein zweiter, in Projekten untersche4tzter Punkt ist der Skalierungs-Zeitpunkt. Bei Per-Monitor-DPI (bbPMv2ab, also Per-Monitor-DPI-Awareness v2) kann sich die effektive DPI e4ndern, wenn ein Fenster den Monitor wechselt oder wenn ein Remote-Desktop-Client die DPI dynamisch anpasst. Wenn dann eine TImageList oder ein Cache nicht korrekt neu aufgebaut wird, sieht man plf6tzlich Icons in falscher Grf6dfe oder mit dem falschen Raster.

TImageList unter High-DPI: typische Fallen in echten Anwendungen

Die TImageList ist historisch ffcr bbkleine Bitmapsab gedacht, mit festen Madfen, 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 150a0% mf6chte Windows aber z.a0B. aus 16d716 eher 24d724 machen. Wenn die Liste auf 16d716 bleibt, wird entweder geclippt oder skaliert an anderer Stelle e4a0b7 beides unschf6n.

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 bb Bitmap bb ImageList bb Draw), entstehen graue Halos oder harte Kanten. Der Effekt ist he4ufig 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 fcbernehmen 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 Bildgrf6dfen oder bbleereab Icons, bis ein Repaint oder ein RecreateWnd passiert.

4) Terminalserver und Remote-Desktop als Realite4tstest

Wenn die App fcber 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 Auflf6sungen bereitstellen statt brutales Upscaling

Die wichtigste Entscheidung ist konzeptionell: Willst du Icons zur Laufzeit aus einer einzigen Basisgrafik hochskalieren (z.a0B. 16d716 bb 32d732), oder stellst du mehrere native Auflf6sungen bereit und we4hlst je nach DPI die passende?

In der Praxis gewinnt fast immer bbmehrere Auflf6sungenab. 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 Kantenqualite4t, und das siehst du auf modernen Displays sofort.

In der VCL-Welt sind ffcr diesen Ansatz heute zwei Bausteine relevant:

• TImageCollection: Container ffcr Bilder in mehreren Grf6dfen/Varianten.
• TVirtualImageList: erzeugt daraus zur Laufzeit eine ImageList in der aktuell benf6tigten Grf6dfe und reagiert auf DPI-c4nderungen.

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 Grfcnde, Icons zur Laufzeit zu skalieren:

• Du le4dst Icons dynamisch (z.a0B. aus einem Plugin-Ordner, kundenspezifische Branding-Pakete, Konfigurationspakete).
• Du willst eine einheitliche Pipeline ffcr verschiedene Quellen (ICO, PNG, SVG) und mf6chtest nicht alle Varianten zur Build-Zeit binden.
• Du erzeugst Icons programmgesteuert (Status-Badges, Overlays, zusammengesetzte Symbole).

Nicht sinnvoll ist Laufzeit-Skalierung, wenn du eigentlich nur klassische Toolbar-Icons aus einem festen Set hast. Dann ist der wartungse4rmste Weg: Mehrere Auflf6sungen sauber ausliefern und die VCL we4hlen lassen.

Wenn du Laufzeit-Skalierung machst, dann mit klaren Regeln:

• Nie aus einem bereits skalierten Bitmap erneut skalieren. Immer von einer Master-Quelle ausgehen (idealerweise vektorbasiert oder hochauflf6send).
• Cache pro Zielgrf6dfe und DPI, sonst skaliert du bei jedem Paint neu e4a0b7 das kostet CPU und kann ruckeln.
• Alpha erhalten: Konvertierungen minimieren, auf 32-bit RGBA setzen, Hintergrund nicht bbmitrasternab.

Pragmatische Architektur: Icon-Pipeline als eigener Baustein

In grf6dferen Anwendungen lohnt es sich, das Thema nicht fcberall zu verstreuen, sondern eine kleine Pipeline zu bauen. Das muss kein Framework sein e4a0b7 eher ein klarer Verantwortungsbereich:

• Icon-Quelle: Woher kommen die Master-Assets (Ressourcen, Dateien, Datenbank, API)?
• Rasterizer/Scaler: Wie wird aus Master bbZielgrf6dfeab erzeugt (Interpolation, ggf. SVG-Render)?
• Cache: Schlfcssel (Icon-ID, Ziel-Pixel, DPI, Theme) und Lebenszyklus (invalidieren bei DPI-Wechsel, Theme-Wechsel, Paketwechsel).
• Consumer-Adapter: Wie kommt das Ergebnis in VCL-Strukturen (TImageList/TVirtualImageList, OwnerDraw, PaintBox)?

Vorteil: Du kannst DPI-Bugs reproduzierbar an einer Stelle debuggen, statt in 40 Forms nach bbwo wird nochmal gescaledab zu suchen.

DPI-Wechsel korrekt behandeln: Ereignisse, Rebuild, Repaint

Unter Windows sind DPI-Wechsel ein eigener Lebenszyklus. In der VCL gibt es je nach Version und DPI-Awareness mehrere Ereignisse/Mechanismen, aber das Grundprinzip bleibt:

• Wenn sich die DPI des Fensters e4ndert, mfcssen bildbasierte Ressourcen, die pixelgenau sein sollen, neu bereitgestellt werden.
• Wenn du ImageLists dynamisch ffcllst, reicht ein blodfes bbInvalidateab oft nicht e4a0b7 du brauchst ein Rebuild der Images in der neuen Zielgrf6dfe.

Ein praxistaugliches Muster ist: Auf DPI-c4nderung (z.a0B. Form-Scale/Monitorwechsel) invalidierst du den Icon-Cache ffcr diese DPI und baust die betroffenen ImageLists neu auf. Wichtig ist, dabei nicht in Paint-Events zu skalieren, sondern in einem kontrollierten Update-Block (Toolbar.BeginUpdate/EndUpdate, ListView-Redraw aus, dann wieder an). So vermeidest du Flackern und halbfertige UI-Zuste4nde.

Warum TImageList so oft unscharf wird: Interpolation, DPI-Rundung, Kanten

Wenn du einmal verstanden hast, dass nicht bbDPIab das Problem ist, sondern Interpolation plus Rundung, lassen sich viele Effekte erkle4ren:

• DPI-Rundung: 125a0% ist kein sauberer Verdoppler. Aus 16 px werden 20 px (16 * 1,25). Aus 24 px werden 30 px. Das sind krumme Zahlen, die Pixelkanten erschweren.
• Resampling-Filter: Bilinear/Bicubic macht Kanten weicher. Das ist ffcr Fotos ok, ffcr Icons oft nicht.
• Subpixel-Effekte: Windows kann je nach Renderpfad Subpixel-Antialiasing nutzen oder nicht. Bei Icons willst du kontrollierte Kanten e4a0b7 und mf6glichst keine mehrfachen Filterstufen.

Wenn du Raster-Icons hast, ist es in vielen Teams ge4ngige Praxis, pro Zielgrf6dfe eigene PNGs zu liefern (16/20/24/32/40/48). Klingt nach viel, ist aber oft weniger Aufwand als jahrelang bbwarum sieht das auf diesem Monitor komisch ausab zu debuggen.

Debugging: Pixelmatsch reproduzierbar machen statt nach Bauchgeffchl zu fixen

High-DPI-Bugs wirken oft zufe4llig. Mit ein paar Checks werden sie deterministisch:

1) DPI und ImageList-Grf6dfe zur Laufzeit loggen

Logge bei Start und bei DPI-Wechsel: CurrentPPI des Forms, Screen.PixelsPerInch (Achtung: das kann System-DPI sein), sowie ImageList.Width/Height der betroffenen Listen. Wenn du nach einem Monitorwechsel noch 16d716 siehst, obwohl du 32 erwartest, ist die Ursache klar: Rebuild fehlt oder kommt zu spe4t.

2) Icons sichtbar vergrf6dfern

Ein schneller Test ist, die Toolbar-Icons tempore4r auf 48 px zu setzen. Schlechte Skalierung springt dann sofort ins Auge. Gute Pipelines bleiben auch bei 48 px scharf, weil sie aus einer passenden Quelle rastern.

3) Theme- und Hintergrundwechsel testen

Halos am Rand sind oft Alpha-/Premultiply-Probleme. Teste auf hell/dunkel und auf Fle4chen mit Farbverlauf. Wenn die Kante je nach Hintergrund anders aussieht, stimmt die Transparenzbehandlung nicht.

4) Remote Desktop / Monitorwechsel als Testskript

Erstelle ein kurzes Testskript ffcr die QS: App starten auf Monitor A (100a0%), Fenster auf Monitor B (150a0%), zurfcck, dann RDP reconnect. Wenn das stabil ist, sind viele Kundenprobleme bereits erschlagen.

Migration in bestehenden Anwendungen: Schrittweise statt Big Bang

In gewachsenen Delphi-VCL-Anwendungen steckt die Icon-Logik oft an vielen Stellen: Menfcs, Toolbars, ActionLists, TreeViews, Statusanzeigen. Ein Big-Bang-Umbau bringt Risiko. Bewe4hrt hat sich ein schrittweises Vorgehen:

• Inventur: Welche ImageLists gibt es? Welche Controls nutzen sie? Welche Grf6dfen werden erwartet?
• Priorisieren: Zuerst die prominentesten Fle4chen (Haupttoolbar, Navigation, Kontextmenfcs).
• 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.

Wichtig: Wenn du parallel alte und neue Pipeline betreibst, dokumentiere klare Regeln. Sonst entsteht eine Mischlandschaft, in der manche Icons scharf sind und andere sichtbar bbaltab wirken.

Performance und Speicher: Laufzeit-Skalierung ohne Nebenwirkungen

Skalierung kostet CPU und Speicher. In einer Business-Software fe4llt das selten im Leerlauf auf, aber beim bbFenster auf neuen Monitor ziehenab oder beim Start mit vielen Forms kann es ruckeln. Drei praktische Leitplanken:

• Cache-Grf6dfe begrenzen: Nicht jede Zwischenstufe ewig halten. Wenn du nur 100a0% und 150a0% brauchst, cache auch nur diese.
• Lazy Build: Icons erst rastern, wenn der Screen sie wirklich braucht. Bei grodfen Menfcs spart das Startzeit.
• Batch-Rebuild: Beim DPI-Wechsel nicht jedes Control einzeln triggern. Ein zentraler Rebuild verhindert redundantes Skalieren.

Wenn du mit TVirtualImageList arbeitest, ist vieles davon bereits als Konzept enthalten e4a0b7 aber du musst trotzdem darauf achten, nicht zuse4tzlich noch eigene Skalierung oben drauf zu bauen.

Fallback-Strategien: Was tun, wenn nicht alle Icon-Grf6dfen vorliegen?

In der Realite4t hast du nicht immer alle Assets in allen Grf6dfen. Dann brauchst du eine klare Fallback-Strategie, um bbzufe4lligeab Ergebnisse zu vermeiden:

• Prefer Downscale: Lieber von 64 px auf 32 px runter als von 16 px auf 32 px hoch.
• Definiere Stufen: Lege fest, welche Zielgrf6dfen du wirklich supportest (z.a0B. 16/20/24/32/40/48) und mappe DPI sauber darauf.
• Transparenz testen: Bei Fallbacks besonders auf Alpha achten e4a0b7 genau dort entstehen Halos.

Ein typischer Fehler ist, bbirgendeineab ne4chste Grf6dfe zu nehmen. Dadurch variiert die wahrgenommene Sche4rfe je nach Icon. Besser ist ein harter, dokumentierter Mapping-Plan.

Wann lohnt sich der Aufwand wirklich?

Es gibt drei klare Indikatoren, dass sich eine saubere High-DPI-Icon-Pipeline lohnt:

• Deine Nutzer arbeiten mit gemischten Monitoren (Laptop + extern) oder viel per RDP.
• Die Anwendung ist langlebig und wird fcber Jahre gepflegt e4a0b7 UI-Wahrnehmung ist Teil der Akzeptanz.
• Du hast ohnehin Modernisierungsschritte vor dir (DPI-Awareness anheben, Controls tauschen, Toolbar-Layout fcberarbeiten).

Wenn die App dagegen nur auf einem festen Kiosk-System mit identischer Auflf6sung le4uft, kann man das Thema minimal halten: eine passende Icon-Grf6dfe liefern, DPI-Awareness sauber setzen, fertig.

Fazit: High-DPI ist kein kosmetisches Detail, sondern eine Rendering-Entscheidung

Unscharfe Icons sind in der VCL selten ein isolierter Fehler, sondern ein Hinweis auf eine unsaubere Kette aus Quellen, Skalierung und Caching. Der robusteste Weg ist, Icons in mehreren Auflf6sungen bereitzustellen und sie fcber eine zentrale Pipeline (z.a0B. ImageCollection/VirtualImageList oder eine eigene Icon-Schicht) konsistent zu liefern. Laufzeit-Skalierung ist dann sinnvoll, wenn du dynamische Quellen oder zusammengesetzte Symbole hast e4a0b7 aber nur mit Master-Quelle, DPI-basiertem Cache und klaren Rebuild-Regeln.

Wenn du konkrete Symptome hast (DPI-Wechsel macht Icons kaputt, Halos am Rand, falsche Grf6dfen nach RDP), lohnt es sich, das Thema gezielt zu isolieren und als kleinen Architekturbaustein zu behandeln, statt pro Form Workarounds zu stapeln. Wenn du dabei Unterstfctzung beim Debugging oder bei einer schrittweisen Modernisierung brauchst, findest du hier den passenden Einstieg: Kontakt zur Net-Base Software GmbH.

Für dieses Thema sind auch Timagelist High Dpi und Delphi Vcl Dpi-Awareness wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.