Hast du mal gemessen, welcher Teil des Codes welchen Anteil an der Gesamtlaufzeit hat? Vielleicht sind die Threads so schnell fertig, dass du davon gar nichts bemerkst, aber der Rest, der im Main-Thread läuft, braucht die meiste Zeit. Kann sein, dass du hier die völlig falsche Stelle optimiert hast! Ein Tipp, um in Zukunft gleich den Flaschenhals zu finden:
Sampling Profiler. (Bei Benutzung in den Compiler-Optionen unbedingt die Mapfile-Generierung aktivieren, sonst hast du sehr wenig davon).
Delphi-Quellcode:
function BitmapToArrayofColor(Bitmap: TBitmap):Colorarray;
VAR i,j: integer;
begin
SetLength(result, Bitmap.Width, Bitmap.Height);
for i := 0 to Bitmap.Width-1 do
for j := 0 to Bitmap.Height-1 do
result[i,j]:=Bitmap.Canvas.Pixels[i,j];
end;
function ArrayofColorToBitmap(AoC: ColorArray):TBitmap;
VAR i,j: integer;
begin
result:=TBitmap.Create;
result.Width:=Length(AoC);
result.Height:=Length(AoC[0]);
for i := 0 to Length(AoC)-1 do
for j := 0 to Length(AoC[0])-1 do
result.Canvas.Pixels[i,j]:=AoC[i,j];
end;
Das wären so Kandidaten. Der Zugriff über
TCanvas.Pixels
ist nämlich unheimlich lahm. Schau dir mal
TBitmap.Scanline
an. Damit kannst du dir wahrscheinlich auch dein ColorArray sparen. Allerdings musst du das Bitmap dann zeilenweise bearbeiten – aktuell scheinst du ja spaltenweise vorzugehen (was übrigens auch aus Caching-Gründen ineffizient ist, da das Bitmap zeilenweise im Speicher liegt. Sprich: eine Bildzeile kann einfach „in einem Rutsch“ eingelesen werden, während bei Pixeln aus verschiedenen Zeilen immer hin und her gesprungen werden muss. Das dürfte hier zwar kaum ins Gewicht fallen, weil andere Stellen viel stärker bremsen, aber dennoch kann man es mal erwähnen).