Mandelbrot-Menge optimieren

[MrMooed]

dumme Frage, aber können die Threads gleichzeitig auf die TBitMap zeichnen ? Denn sie sollten dank ScanLine ja niemals in der selben Zeile sein

Ansonsten habe ich nachgedacht die Zeilen in Abhängigkeit von den Kernen zu erstellen, da es evtl. zu viel Aufwand ist X-kleine Threads zu erstellen als z.B. 8 die etwas mehr zu rechnen haben. Diese 8 Streifen könnten jeweils eine eigene BitMap haben, die dann im MainThread zusammengeklebt werden

Zitat von sx2008:

Das Wurzelziehen mit SQRT() sollte man bei der Mandelbrotmenge unbedingt vermeiden, denn es kostet viel Zeit.
In der rekursiven Variante wird ja auf (A < 2) abgefragt.
Lässt man das Wurzelziehen weg, dann muss auch die Konstante quadriert werden (2*2=4):

Also ich habe gerade mal die Abbruchbedingung durch 4 ersetzt und die Wurzel entfernt - nun habe ich hübsche bunte Balken aber kein Apfelmänchen

Delphi-Quellcode:

  if (i < 100) and (A < 4)
    then begin
           nX := (X*X) - (Y*Y) + X_Ko;
           nY := 2*X*Y + Y_Ko;
           nA := nX*nX + nY*nY;
           result := rechne(X_Ko, Y_Ko, nX, nY, nA, i+1);
         end;

//Edit:
Kann die .Execute nicht auf andere Methoden zugreifen ? Schutzklassen sollten da ja keine Probleme bereiten .. aber wenn ich meine 'rechne' function in der .Execute aufrufe passiert nichts - kopiere ich die function hinein läuft es ?!

[sx2008]

Zitat von MrMooed:

Also ich habe gerade mal die Abbruchbedingung durch 4 ersetzt und die Wurzel entfernt - nun habe ich hübsche bunte Balken aber kein Apfelmänchen

Dann hast du irgendwo noch einen anderen Fehler.
Was ich über das Wurzelziehen und dessen Vermeidung geschrieben habe ist richtig und ist eigentlich in jedem Code so umgesetzt.
Z.B. auf Wikipedia http://de.wikipedia.org/wiki/Mandelb...es_Bildpunktes

[MrMooed]

komischer weise tritt dieses Fehlverhalten nur bei der Rekursiven Variante auf
Das finde ich dann doch sehr seltsam .. kann mich da jemand aufklären was mein Denkfehler bei der Rekursion ist ?
Strange..

[Delphi-Laie]

Zitat von MrMooed:

Nun wollte ich hier mal nachfragen ob evtl. jemand Tipps hat was ich an meiner Berechnung schneller machen (bzw. optimieren) kann.

Wollte? Willst du es jetzt nicht mehr?

Tue es doch einfach!

Ehe du es tust, um es abzukürzen: Ein gewaltiges Beschleunigungspotential ergibt sich dadurch, daß man (mehr oder weniger) kleine (rechteckige, am besten quadratische) Flächen gleich komplett färbt: Sind ihre 4 Eckpunkte, die man als erstes berechnet, gleichfarbig, so ist es mit großer Wahrscheinlichkeit das gesamte von ihnenn eingehüllte Viereck. Um Irrtümer anzahlig zu reduzieren, kann man ja auch rekursiv vorgehen und in größeren Vierecken kleinere auf gleiche Weise prüfen und ggf. füllen. Dagegen sind Scanline und Threads läppisch, obwohl beide natürlich auch ihre Berechtigung und Vorteile haben.

[Namenloser]

Zitat von Delphi-Laie:

Ehe du es tust, um es abzukürzen: Ein gewaltiges Beschleunigungspotential ergibt sich dadurch, daß man (mehr oder weniger) kleine (rechteckige, am besten quadratische) Flächen gleich komplett färbt: Sind ihre 4 Eckpunkte, die man als erstes berechnet, gleichfarbig, so ist es mit großer Wahrscheinlichkeit das gesamte von ihnenn eingehüllte Viereck. Um Irrtümer anzahlig zu reduzieren, kann man ja auch rekursiv vorgehen und in größeren Vierecken kleinere auf gleiche Weise prüfen und ggf. füllen.

Und was genau sollte daran schneller sein? Bei einem Fraktal muss sowieso der Wert für jeden Pixel einzeln berechnet werden, und die Anzahl der zu füllenden Pixel wird so auch nicht reduziert.

[Delphi-Laie]

Zitat von NamenLozer:

Und was genau sollte daran schneller sein?

Die oft fehlenden Iterationen.

Zitat von NamenLozer:

Bei einem Fraktal muss sowieso der Wert für jeden Pixel einzeln berechnet werden,

"Muss" muß gar nicht. Es gibt in vielen Flächenfraktalen, so auch dem Apfelmännchen, viele (ziemlich) einfarbige Gebiete, bei denen man mit hoher Treffsicherheit eben annehmen (neupseudodeutsch "davon ausgehen") kann, daß 4 gleichfarbige Eckpunkte ein komplett gleichfarbiges Gebiet umschließen.

Fällt nun der Groschen?

Ausgedacht habe ich mir das nicht, sondern schon vor ca. 20 Jahren (!) in einem DOS-Fraktalprgramm wahrgenommen.

Zitat von NamenLozer:

und die Anzahl der zu füllenden Pixel wird so auch nicht reduziert.

Wer behauptet denn anderes?

[Namenloser]

Ich kann mir nur schwer vorstellen, dass dabei keine Artefakte auftreten...

[MrMooed]

Zitat von Delphi-Laie:

Sind ihre 4 Eckpunkte, die man als erstes berechnet, gleichfarbig, so ist es mit großer Wahrscheinlichkeit das gesamte von ihnenn eingehüllte Viereck.

also nehme ich einfach irgendwo ein Quadrat und berechne die Eckpunkte ? Halte ich irgendwie für ziemlich spekulativ Ich habe mal in einem Bild markiert was passiert wenn man die falschen 4 Punkte erwischt (die trotzdem die selbe Farbe haben) Dann wäre nämlich der Inhalt futsch obwohl noch Fraktale vorhanden wären.

[Bummi]

Mein Versuch die Auswirkung von Threads bei bestimmten Randbedingungen zu untersuchen ...

[Neutral General]

Zu der Sache mit dem Bitmap und den der Aufteilung der Arbeit unter den Threads nach Scanlines:

Unabhängig davon ob man das (bzgl. Threadsicherheit) so machen kann/darf:

Ich habe dem Benutzer (aus Spaß) die Möglichkeit gegeben das Mandelbrot selbst einzufärben. Also je nachdem bei wie vielen Iterationen der Pixel "rausfliegt" diesen Pixel anders einfärben zu lassen. Wenn man in der Palette 10 Einträge hat dann bekommt ein Pixel der nach 11. Iterationen rausfliegt wieder die 1. Farbe.

Das Wechseln der Palette ist um einiges leichter und schneller wenn man nicht direkt auf ein Bitmap zeichnet sondern die Anzahl der Iterationen pro Pixel in einem 2D-Array speichert. So kann man das Mandelbrot schnell und einfach neu einfärben ohne alles neu berechnen zu müssen

Ist jetzt natürlich kein Tipp mit dem man die Performance der Berechnung steigern kann, aber falls du sowas vorhast, dann ist das Zwischenspeichern in einem Array sicher zu empfehlen

Edit: Ich hoffe mein Text ist nicht zu verwirrend geschrieben