Ich bin gerade etwas verwirrt bzgl. des konkreten Anwendungsfalls. Wenn doch im eigenen Programm ganz klar definiert ist welche Operationen das Zufügen von Transparenz bewirken können, ist es doch ein vergleichsweise simples Unterfangen eine entsprechende OnChange-Methode zu implementieren, die ein simples Flag setzt, dass man dann beim Zeichnen bloß immer wieder nur auswerten muss. Dabei sollten dann selbst die ursprünglichen 80ms kaum noch ins Gewicht fallen.
Wenn aber doch, dann wäre ggf. ein Blick auf die Zeichenroutinen am Ende viel zielführender als solch eine "quasi-early-out" Prüfung. Im Zweifel schaue man sich mal an, wie die GR32 dies bei ihrer Implementierung von Layers im TImage32 macht. Diese Lib ist da
imho mit das schnellste was man ohne Parallelisierung bekommen kann (obwohl hier SIMD-Routinen in
ASM eingesetzt werden). (Wenn ich mich recht erinnere benutzen die zudem u.a. ein per-Pixel-Skipping bei nicht- und volltransparenten Pixeln um das Verrechnen zu sparen.)
Es sollte auf halbwegs aktuellen PCs ein sprichwörtlicher Pups sein, zahlreiche Layer halbtransparent übereinander zu zeichnen. Eine Vorab-Prüfung kann meiner Einschätzung nach fast nur eine verschlechternde "Optimierung" werden, egal wie pfiffig man sie implementiert.
(Bei der GR32 spielt sicherlich auch eine sehr große Rolle, dass alle Rechnungen Integer-Basiert sind! Vielleicht lohnt sich am Ende sogar der Einsatz der ganzen Lib.)
Nur um das nochmals klar zu stellen: Wenn es rein um die Prüfung ginge, wären die hier gemachten Anstrengungen sicherlich sinnvoll. Für die Anwendung des Übereinanderzeichnens hingegen, meiner Einschätzung nach, nicht.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)