Was Delphi-Laie da so unsympathisch beschreibt, ist der erste Schritt zu einem Quad-Tree. Dieser erste Schritt kann, bei passend feiner Unterteilung und etwas Glück, relativ artefaktfrei sein - kann aber auch hässlich werden. Praktisch alle Verfahren, die die Iteration von Zwischenpixeln auslassen, haben mit Artefakten zu kämpfen. Manche weniger auffällig, andere sind ganz gut kaschierbar, aber es bleibt ein Behelf. Auch ein Quad-Tree ist hier noch als Krücke anzusehen, da man für die "Ich muss weiter unterteilen"-Bedingung ja doch wieder eine Auswahl an Punkten in den Quadraten durchitereiren muss - und an dieser Auswahl hängt dann, ob man es nicht doch hier und da zu grob getrieben hat.
Iterativ machen, Verwendung von Scanline (das vor allen Dingen! .Pixels[] macht vieeeeel zunichte!) und Multithreading sollte schon einen mächtigen boost geben. Man kann zwar relativ gefahrfrei Scanlines des selben Bitmaps in mehreren Threads beschreiben (so lange man sich immer strikt die Zeilen getrennt hält), aber ich würde hier auch zu einem Array als Zwischen-Puffer tendieren. Eben schon allein für die Möglichkeiten der variablen Farbgebung ohne Neuberechnung.
Und WENN man schon multithreaded, warum nicht gleich ganz freaky werden?
Das ganze ist ein Paradeeinsatz für
GPGPU. Jeder Pixel wird unabhängig von allen anderen berechnet, also hat man eine wunderbare und feine Granularität des Problems. Anfangs die ganzen Bildkoordinaten in eine float/float Textur gießen, einen Shader-Kernel machen der eine Iteration macht, und das Ergebnis in eine zweite Textur schreibt. Texturen tauschen, und nochmal durch den Shader jodeln - bis zur gewünschten Iterationstiefe. Die finale Textur kann dann ähnlich des o.g. Arrays als Basis zum Farbbild dienen - auch das ließe sich als hübscher Kernel realisieren. Aber das ist eher Stufe 9,5.
"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)