VCL High-DPI: Κλιμάκωση εικονιδίων κατά την εκτέλεση και αποφυγή θόλωσης εικονοστοιχείων σε TImageList

Όποιος τρέχει VCL-εφαρμογές σε σύγχρονους Windows-πελάτες, αργά ή γρήγορα θα συναντήσει το ίδιο σύμπτωμα: τα εικονίδια εμφανίζονται σε 125%/150%/200% θαμπά, ξεφτισμένα ή αποκτούν γκρίζο περίγραμμα. Ακριβώς εδώ γίνεται πρακτικό το θέμα VCL High-DPI Icons: όχι επειδή το High-DPI είναι νέο, αλλά επειδή τα προβλήματα συνήθως εμφανίζονται στην καθημερινή λειτουργία — σε Terminalserver, στην αλλαγή dock του φορητού ή μόλις υπάρχουν διαφορετικά DPI ανά οθόνη.

Το βασικό ζήτημα σχεδόν ποτέ δεν είναι ότι το PNG είναι κατεστραμμένο, αλλά η pipeline: από πού προέρχεται το εικονίδιο (resource, αρχείο, SVG, font), με ποια μορφή παραδίδεται, πώς καταλήγει στην TImageList και ποιος κλιμακώνει πότε με ποιο τρόπο. Στην VCL συναντώνται επιπλέον πολλοί όροι που πρέπει να διαχωριστούν: DPI-Awareness (αν Windows κλιμακώνει την εφαρμογή ή η εφαρμογή κλιμακώνει τον εαυτό της), Per-Monitor-DPI (η κάθε οθόνη μπορεί να έχει διαφορετικό DPI) και ImageList-Strategie (να διατηρούνται πολλαπλές αναλύσεις ή να γίνεται rasterizing σε χρόνο εκτέλεσης).

Σε αυτό το άρθρο δεν πρόκειται για συζητήσεις UI-design, αλλά για μια καθαρή, λειτουργικά ασφαλή προσέγγιση: να κλιμακώνονται τα εικονίδια σε χρόνο εκτέλεσης, αλλά με τέτοιον τρόπο ώστε να μην γίνονται pixelmatsch, να παραμένουν τα κανάλια Alpha ακέραια και οι αλλαγές DPI να λειτουργούν χωρίς τρεμόπαιγμα ή λανθασμένα μεγέθη εικόνων. Προστίθενται παγίδες, συμβουλές για debugging και μια ειλικρινής εκτίμηση για το πότε αξίζει ο επιπλέον κόπος.

Warum Pixelmatsch entsteht: Skalierungskette in der VCL verstehen

Ο συχνότερος λόγος για θαμπά εικονίδια είναι ένα μονομερές down-/upscaling τη λάθος στιγμή. Κλασική ροή στη Legacy-VCL:

• Η εφαρμογή παρέχει εικονίδια μόνο σε 16×16 ή 24×24.
• Windows ή η VCL κλιμακώνει σε 20×20 / 32×32 / 48×48.
• Ο scaler χρησιμοποιεί μια παρεμβολή που είναι κατάλληλη για φωτογραφίες, αλλά για pixel-γραφικά θολώνει τις ακμές.
• Επιπλέον, η διαφάνεια (Alpha) συμπιέζεται σε λογική μάσκας ή μετατρέπεται πολλαπλά.

Γίνεται ιδιαίτερα προβληματικό όταν συμβαίνουν πολλαπλά βήματα κλιμάκωσης: για παράδειγμα όταν η ImageList ήδη παραδίδει ένα κλιμακωμένο bitmap και στη συνέχεια Windows λόγω DPI-unaware ή System-DPI το κλιμακώνει ξανά. Αποτέλεσμα: διπλά θαμπό αποτέλεσμα.

Ένα δεύτερο, στα έργα υποτιμημένο σημείο είναι η στιγμή της κλιμάκωσης. Σε Per-Monitor-DPI (PMv2, δηλαδή Per-Monitor-DPI-Awareness v2) η αποτελεσματική DPI μπορεί να αλλάξει όταν ένα παράθυρο αλλάζει οθόνη ή όταν ένας Remote-Desktop-Client προσαρμόζει δυναμικά το DPI. Αν τότε μια TImageList ή ένα cache δεν αναδημιουργηθεί σωστά, ξαφνικά βλέπεις εικονίδια σε λανθασμένο μέγεθος ή με λανθασμένο raster.

TImageList unter High-DPI: typische Fallen in echten Anwendungen

Η TImageList έχει ιστορικά σχεδιαστεί για μικρά bitmaps, με σταθερές διαστάσεις, δείκτες και σχετικά άκαμπτη λογική αποθήκευσης. Υπό High-DPI αυτό οδηγεί σε πρακτικές παγίδες:

1) Σταθερά wired Width/Height

Πολλές φόρμες VCL ορίζουν το ImageList.Width/Height στην ώρα του σχεδιασμού και το αφήνουν έτσι. Σε 150 % όμως συχνά Windows θα ήθελε π.χ. από 16×16 μάλλον 24×24. Αν η λίστα μείνει στα 16×16, είτε γίνεται clipping είτε γίνεται κλιμάκωση αλλού — και τα δύο είναι ανεπιθύμητα.

2) PNG-Alpha και λογική μάσκας

Ανάλογα με την Delphi-έκδοση και τα VCL-controls, καταλήγεις γρήγορα σε υβριδική λειτουργία: PNGs με alpha αποθηκεύονται εσωτερικά μερικές φορές ως 32-bit Bitmap, άλλες φορές ως Mask+Color. Μόλις κάνεις πολλαπλές μετατροπές (PNG → Bitmap → ImageList → Draw), εμφανίζονται γκρίζα halos ή σκληρά άκρα. Το αποτέλεσμα είναι συχνά ευαίσθητο στο background: σε σκούρα toolbar φαίνεται χειρότερα απ’ ό,τι σε ένα φωτεινό panel.

3) Αλλαγές DPI κατά την εκτέλεση: caches, handles, OwnerDraw

Ορισμένα controls κάνουν cache της απεικόνισης ή αναλαμβάνουν ImageList-handles σε μια χρονική στιγμή όπου το DPI δεν είναι ακόμα τελικό. Ιδίως σε Toolbars, TreeViews/ListViews και σε OwnerDraw σενάρια, μετά από αλλαγές DPI βλέπει κανείς περιστασιακά λανθασμένα μεγέθη εικόνων ή ξεθωριασμένα/άδεια icons, μέχρι να συμβεί ένα Repaint ή ένα RecreateWnd.

4) Terminalserver και Remote-Desktop ως τεστ πραγματικότητας

Όταν η εφαρμογή χρησιμοποιείται μέσω RDP, οι αλλαγές DPI και τα session-reconnects δεν είναι σπάνια. Εκεί ακριβώς μια μη-ανθεκτική στρατηγική ImageList αποτυγχάνει: ο χρήστης βλέπει μετά το reconnect θολωμένα icons ή λανθασμένα κλιμακωμένες γραμμές εργαλείων, ενώ τοπικά όλα ήταν εντάξει.

Καθαρή προσέγγιση: Παροχή πολλαπλών αναλύσεων αντί για βίαιο upscaling

Η σημαντικότερη απόφαση είναι εννοιολογική: Θέλεις να κλιμακώσεις τα icons κατά την εκτέλεση από μία και μοναδική βάση (π.χ. 16×16 → 32×32), ή παρέχεις πολλές εγγενείς αναλύσεις και επιλέγεις την κατάλληλη ανά DPI;

Στην πράξη σχεδόν πάντα υπερισχύει η «πολλαπλές αναλύσεις». Το upscaling είναι αποδεκτό όταν η πηγή είναι διανυσματική (SVG, icon-font) ή όταν χρειάζεσαι πραγματικά μόνο μετρίους παράγοντες. Μόλις αυξήσεις σημαντικά από ένα μικρό raster, χάνεις ποιότητα στις ακμές, και αυτό φαίνεται άμεσα στις σύγχρονες οθόνες.

Στον κόσμο VCL για αυτήν την προσέγγιση σήμερα αφορούν κυρίως δύο στοιχεία:

• TImageCollection: container για εικόνες σε πολλαπλά μεγέθη/παραλλαγές.
• TVirtualImageList: δημιουργεί από αυτά κατά την εκτέλεση μια ImageList στο απαιτούμενο μέγεθος και αντιδρά στις αλλαγές DPI.

Αυτό δεν λύνει όλα τα προβλήματα, αλλά μεταφέρει το ζήτημα στο σωστό επίπεδο: ορίζεις τις πηγές εικόνων καθαρά και η κλιμάκωση/επιλογή γίνεται συνεπώς.

Κλιμάκωση VCL High-DPI icons κατά την εκτέλεση: Πότε είναι λογικό (και πότε όχι)

Υπάρχουν βάσιμοι λόγοι για να κλιμακώσεις icons κατά την εκτέλεση:

• Φορτώνεις icons δυναμικά (π.χ. από έναν φάκελο plugin, προσαρμοσμένα πακέτα branding, πακέτα ρυθμίσεων).
• Θέλεις μια ενιαία pipeline για διάφορες πηγές (ICO, PNG, SVG) και δεν θέλεις να δέσεις όλες τις παραλλαγές κατά το build-time.
• Παράγεις icons προγραμματικά (status-badges, overlays, συνθετικά σύμβολα).

Δεν έχει νόημα η κλιμάκωση σε χρόνο εκτέλεσης αν έχεις στην πραγματικότητα μόνο κλασικά εικονίδια toolbar από ένα σταθερό σετ. Σε αυτή την περίπτωση ο πιο φιλικός προς τη συντήρηση τρόπος είναι: να παραδίδεις καθαρές πολλαπλές αναλύσεις και να αφήνεις την VCL να επιλέξει.

Αν κάνεις κλιμάκωση κατά το runtime, τότε με σαφείς κανόνες:

• Ποτέ να μην κλιμακώνεις εκ νέου από μία ήδη κλιμακωμένη bitmap. Πάντα να ξεκινάς από μία master πηγή (ιδανικά διανυσματική ή υψηλής ανάλυσης).
• Cache ανά τελικό μέγεθος και DPI, αλλιώς θα κλιμακώνεις ξανά σε κάθε Paint — αυτό κοστίζει CPU και μπορεί να προκαλέσει κολλήματα.
• Διατήρηση alpha: Ελαχιστοποίησε τις μετατροπές, χρησιμοποίησε 32-bit RGBA, και μην συγχωνεύεις/επίπεδοποιείς το υπόβαθρο κατά τη ραστεροποίηση.

Πραγματιστική αρχιτεκτονική: Pipeline εικονιδίων ως ανεξάρτητο στοιχείο

Σε μεγαλύτερες εφαρμογές αξίζει να μην απλώνεις το θέμα παντού, αλλά να χτίσεις μία μικρή pipeline. Δεν χρειάζεται να είναι framework — περισσότερο ένας σαφής τομέας ευθύνης:

• Πηγή εικονιδίων: Από πού προέρχονται τα master assets (resources, αρχεία, βάση δεδομένων, API);
• Rasterizer/Scaler: Πώς παράγεται από το master στο τελικό μέγεθος (interpolation, ενδεχομένως SVG-render);
• Cache: Κλειδί (Icon-ID, τελικά pixel, DPI, Theme) και κύκλος ζωής (invalidate σε αλλαγή DPI, αλλαγή Theme, αλλαγή πακέτου).
• Consumer-Adapter: Πώς καταλήγει το αποτέλεσμα σε VCL-δομές (TImageList/TVirtualImageList, OwnerDraw, PaintBox);

Πλεονέκτημα: Μπορείς να αναπαράγεις και να αποσφαλματώσεις DPI-bugs σε ένα σημείο, αντί να ψάχνεις σε 40 Forms «πού ξανακλιμακώνεται».

Σωστή διαχείριση αλλαγών DPI: Γεγονότα, Rebuild, Repaint

Υπό Windows οι αλλαγές DPI είναι δικός τους κύκλος ζωής. Στην VCL υπάρχουν, ανάλογα με την έκδοση και την DPI-awareness, διάφορα γεγονότα/μηχανισμοί, αλλά η βασική αρχή παραμένει:

• Όταν αλλάζει το DPI του παραθύρου, οι εικόνες/πόροι που πρέπει να είναι pixel-ακριβείς πρέπει να παρασχεθούν ξανά.
• Αν γεμίζεις ImageLists δυναμικά, ένα απλό Invalidate συχνά δεν αρκεί — χρειάζεσαι ένα Rebuild των εικόνων στη νέα τελική διάσταση.

Ένα πρακτικό πρότυπο είναι: Σε αλλαγή DPI (π.χ. Form-Scale/μετακίνηση μεταξύ monitors) invalidάρεις το cache των εικονιδίων για αυτό το DPI και αναδημιουργείς τις επηρεασμένες ImageLists. Σημαντικό: μην κλιμακώνεις μέσα σε Paint-Events, αλλά σε έναν ελεγχόμενο update-block (Toolbar.BeginUpdate/EndUpdate, ListView-Redraw off, μετά on). Έτσι αποφεύγεις τρεμόπαιγμα και ημιτελείς καταστάσεις UI.

Γιατί το TImageList συχνά γίνεται θολό: Interpolation, στρογγυλοποίηση DPI, ακμές

Μόλις καταλάβεις ότι το πρόβλημα δεν είναι το απλώς το DPI, αλλά η interpolation συν η στρογγυλοποίηση, εξηγούνται πολλά εφέ:

• Στρογγυλοποίηση DPI: 125% 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 für Fotos ok, für Icons oft nicht.
• Subpixel-Effekte: Windows kann je nach Renderpfad Subpixel-Antialiasing nutzen oder nicht. Bei Icons willst du kontrollierte Kanten — und möglichst keine mehrfachen Filterstufen.

Wenn du Raster-Icons hast, ist es in vielen Teams gängige Praxis, pro Zielgröße eigene PNGs zu liefern (16/20/24/32/40/48). Klingt nach viel, ist aber oft weniger Aufwand als jahrelang zu debuggen, warum das auf diesem Monitor komisch aussieht.

Debugging: Pixelmatsch reproduzierbar machen statt nach Bauchgefühl zu fixen

High-DPI-Bugs wirken oft zufällig. Mit ein paar Checks werden sie deterministisch:

1) DPI und ImageList-Größe 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 16 siehst, obwohl du 32 erwartest, ist die Ursache klar: Rebuild fehlt oder kommt zu spät.

2) Icons sichtbar vergrößern

Ein schneller Test ist, die Toolbar-Icons temporär 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 Flächen mit Farbverlauf. Wenn die Kante je nach Hintergrund anders aussieht, stimmt die Transparenzbehandlung nicht.

4) Remote Desktop / Monitorwechsel als Testskript

Erstelle ein kurzes Testskript für die QS: App starten auf Monitor A (100%), Fenster auf Monitor B (150%), zurück, 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: Menüs, Toolbars, ActionLists, TreeViews, Statusanzeigen. Ein Big-Bang-Umbau bringt Risiko. Bewährt hat sich ein schrittweises Vorgehen:

• 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.

Σημαντικό: Τεκμηρίωσε σαφείς κανόνες αν λειτουργείς παράλληλα με την παλιά και τη νέα Pipeline. Διαφορετικά δημιουργείται ένα μεικτό τοπίο, στο οποίο κάποια εικονίδια είναι ευκρινή και άλλα εμφανώς θολά.

Performance und Speicher: Laufzeit-Skalierung ohne Nebenwirkungen

Η κλιμάκωση κοστίζει CPU και μνήμη. Σε μια επιχειρησιακή εφαρμογή αυτό σπάνια φαίνεται σε κατάσταση αδράνειας, αλλά μπορεί να κάνει την εφαρμογή να τραυλίζει όταν το παράθυρο μεταφέρεται σε νέο οθόνη ή κατά την εκκίνηση με πολλά Forms. Τρεις πρακτικές οδηγίες:

• Περιορισμός μεγέθους cache: Μην διατηρείτε κάθε ενδιάμεσο μέγεθος επ‘ αόριστον. Αν χρειάζεστε μόνο 100% και 150%, κάντε cache μόνο αυτά.
• Lazy Build: Ραστεροποιείστε τα εικονίδια μόνο όταν η οθόνη τα χρειάζεται πραγματικά. Σε μεγάλα μενού αυτό εξοικονομεί χρόνο εκκίνησης.
• Batch-Rebuild: Σε αλλαγή DPI μην ενεργοποιείτε ξεχωριστά κάθε Control. Ένας κεντρικός Rebuild αποτρέπει το επαναλαμβανόμενο κλιμάκωμα.

Αν δουλεύετε με TVirtualImageList, πολλά από αυτά είναι ήδη ενσωματωμένα ως έννοια, αλλά πρέπει παρ‘ όλα αυτά να προσέξετε να μην εφαρμόσετε επιπλέον δικά σας στρώματα κλιμάκωσης από πάνω.

Fallback-Strategien: Was tun, wenn nicht alle Icon-Größen vorliegen?

Στην πραγματικότητα δεν έχετε πάντα όλα τα assets σε κάθε μέγεθος. Χρειάζεστε τότε μια σαφή στρατηγική fallback για να αποφύγετε τυχαία ή μη αναμενόμενα αποτελέσματα:

• Prefer Downscale: Καλύτερα να υποβαθμίσετε από 64 px σε 32 px παρά να μεγεθύνετε από 16 px σε 32 px.
• Definiere Stufen: Καθορίστε ποια τελικά μεγέθη υποστηρίζετε πραγματικά (π.χ. 16/20/24/32/40/48) και κάντε σαφή mapping του DPI σε αυτά.
• Transparenz testen: Σε fallbacks δώστε ιδιαίτερη προσοχή στο κανάλι αλφα — εκεί συχνά δημιουργούνται halos.

Ένα συνηθισμένο λάθος είναι να παίρνει κανείς οποιοδήποτε „επόμενο“ μέγεθος. Αυτό οδηγεί σε μεταβλητή αντιληπτή οξύτητα ανά εικονίδιο. Καλύτερα ένας αυστηρός, τεκμηριωμένος mapping‑πλάνος.

Wann lohnt sich der Aufwand wirklich?

Υπάρχουν τρεις σαφείς ενδείξεις ότι αξίζει μια καθαρή High‑DPI‑icon‑pipeline:

• Οι χρήστες σας εργάζονται με μικτό εξοπλισμό οθονών (laptop + εξωτερική) ή πολύ μέσω RDP.
• Η εφαρμογή είναι μακρόβια και θα συντηρηθεί επί χρόνια — η αντίληψη του UI είναι μέρος της αποδοχής.
• Έχετε ήδη προγραμματισμένα βήματα εκσυγχρονισμού (ανέβασμα DPI‑Awareness, αντικατάσταση Controls, ανασχεδίαση toolbar‑layout).

Αν η εφαρμογή τρέχει όμως αποκλειστικά σε ένα σταθερό kiosk‑σύστημα με την ίδια ανάλυση, μπορείτε να κρατήσετε το θέμα στο ελάχιστο: παρέχετε ένα κατάλληλο μέγεθος εικονιδίου, ρυθμίστε σωστά την DPI‑Awareness και τελειώσατε.

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

Τα θολά εικονίδια στη VCL σπάνια είναι μεμονωμένο σφάλμα — συνήθως δείχνουν μια ακατάλληλη αλυσίδα πηγών, κλιμάκωσης και caching. Η πιο αξιόπιστη προσέγγιση είναι να παρέχετε εικονίδια σε πολλαπλές αναλύσεις και να τα διανείμετε συνεπώς μέσω μιας κεντρικής pipeline (π.χ. ImageCollection/VirtualImageList ή μιας ιδιόκτητης στρώσης εικονιδίων). Η κλιμάκωση σε χρόνο εκτέλεσης είναι χρήσιμη όταν έχετε δυναμικές πηγές ή συνθετικά σύμβολα — αλλά μόνο με πηγή master, cache βάσει DPI και σαφείς κανόνες Rebuild.

Αν έχετε συγκεκριμένα συμπτώματα (η αλλαγή DPI καταστρέφει εικονίδια, halos στα όρια, λάθος μεγέθη μετά από RDP), αξίζει να απομονώσετε το θέμα και να το αντιμετωπίσετε ως μικρό αρχιτεκτονικό στοιχείο, αντί να στοιβάζετε workarounds ανά φόρμα. Αν χρειάζεστε υποστήριξη στο debugging ή σε μια σταδιακή εκσυγχρόνιση, θα βρείτε εδώ το κατάλληλο σημείο εκκίνησης: Kontakt zur Net-Base Software GmbH.

Για αυτό το θέμα είναι επίσης σημαντικά τα Timagelist High Dpi και Delphi Vcl Dpi-Awareness. Το άρθρο εντάσσει αυτές τις πτυχές με κατανοητό τρόπο και δείχνει τι έχει σημασία στην καθημερινή πρακτική.

Συζητήστε έργο ή σχέδιο εκσυγχρονισμού με Net-Base.