Das Programm wird immer schöner.

Bezüglich Geschwindigkeitserhöhung habe ich leider nichts beizutragen, wohl aber bezüglich Programmergonomie (oder auch "-intelligenz"): Beim Starten und beim Größenändern des Formulars erscheint das Bild nicht von allein, es muß sich mit "Darstellung" besorgt werden. Könnte man diese Ereignisse nicht für eine automatische Darstellung verarbeiten? Müßte nach meiner bescheidenen Erfahrung mit Delphi nicht allzu schwierig sein.

Ergänzung: Beim Größenändern wäre evtl. ein Zeitverzug vonnöten, ansonsten, konkret bei "manuellem" Resize, würde das Bildzeichnen vielleicht zu oft aufgerufen werden. Vor dem gleichen Problem stand ich bei meinem Sortieranimationsprogramm beim Bedienen der Spinedits und konnte dank Hilfe lösen. Ohne Zeitverzug verfing sich mein Programm irgendwann in irgendeiner Endlosschleife.

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Könnte man diese Ereignisse nicht für eine automatische Darstellung verarbeiten? Müßte nach meiner bescheidenen Erfahrung mit Delphi nicht allzu schwierig sein.

Danke für den Hinweis.
Ich habe es sofort eingebaut, in dem ich die paintboxpaint-Methode mit der Schalter-Methode verbunden habe. Da die Zeichnung jetzt sehr schnell geht, ist das auch möglich, wenn gleich ein kurzes Flackern auftritt.
In der (bald) folgenden Variante 12 ist es dann drin.
Beste Grüße
Mathematiker

Hallo,

diese ständigen Revisionen...
Ich habe mal meine uplasma.pas angehängt, und hoffe mal, dass sie auch unter Delphi kompiliert.
Ich habe die Bildausgabe aus der Zeitbestimmmung rausgeschmissen, dies war zu dominant.

Meine Version ist so ein wenig schneller.
Am besten mit Faktor = 0 und zebbow statt firestm

Gruß Horst

Hallo Horst_H,

Horst_H hat folgendes geschrieben :

diese ständigen Revisionen...

Entschuldigung, aber ich denke es ist besser, wenn die aktuelle Variante zum Download bereitsteht.
Nach der Revision 12 wird es aber wohl weniger werden, da ich vermute, dass nur noch eine völlig neue Idee eine deutliche Beschleunigung bewirkt. Und die haben wir im Moment noch nicht.

Horst_H hat folgendes geschrieben :

Ich habe mal meine uplasma.pas angehängt, und hoffe mal, dass sie auch unter Delphi kompiliert.

Kein Problem und vielen Dank. Ich habe jetzt in das Programm wahlweise Deine und meine Routine eingebaut. Damit kann jeder entscheiden, welche er nutzt.
Auf meinem Rechner ist es so, dass Dein Vorschlag nahezu bei jeder Fenstergröße nur so viele Punkte berechnet, wie notwendig. Meine Lösung ist da noch schlechter.
Allerdings, und das verwundert mich, ist meine Fensterroutine für fast quadratische Abbildungen etwas schneller.

Beste Grüße
Mathematiker

Ich wollte Dich bzw. dieses Dein Programm schon wieder über den grünen Klee loben, doch bei der manuellen Größenänderung (Resize, indem man am Formularrand "anfaßt") kommt vermutlich der Fehler, den ich schon einmal in dieser Diskussion bemängelte (Anhang). Ja, es kommt ggf. sogar eine "Fehlermeldungsausgabetreppe" nach rechts unten, die man von Windows nur allzu leidlich kennt.

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Ich wollte Dich bzw. dieses Dein Programm schon wieder über den grünen Klee loben, doch bei der manuellen Größenänderung (Resize, indem man am Formularrand "anfaßt") kommt vermutlich der Fehler, den ich schon einmal in dieser Diskussion bemängelte (Anhang).

Nochmals Entschuldigung! Dieser Fehler sieht nach Problemen beim Laden der Farbpalette palette.c00 aus. Ich habe jetzt das neue Laden der Farben beim Zeichnen eines Bildes ausgegliedert.

Alternativ werde ich prüfen, ob ich die Farben nicht komplett in die Resource einbinden kann. Dann muss palette.c00 nicht mehr vorhanden sein und wahrscheinlich geht es auch schneller.
Sobald ich eine endgültige Lösung habe, melde ich mich noch einmal hier und füge die neue Revision ein.

Beste Grüße
Mathematiker

Dann bin wohl eher ich derjenige, der um Entschuldigung bitten muß.

Meine Programmprüfung sah jedesmal einfach so aus, im Entpackprogrammfenster auf die Exe zu klicken und dann mit dieser zu werkeln, womit die Palette natürlich nicht verfügbar ist. Mit ihr scheint es aber zu klappen. Ich sah diese Palettendatei durchaus auch, konnte sie aber nicht zuordnen (daß es sich um irgendeine externe Datendatei handelt, ahnte ich aber bereits). Mühsamer zu programmieren, aber aussagekräftiger wäre eine Fehlerausgabe, die die fehlende Datei moniert.

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Dann bin wohl eher ich derjenige, der um Entschuldigung bitten muß.

Musst Du nicht, ich hätte auch die Farben in die Resource packen und somit die Fehlerquelle verhindern können, was ich jetzt getan habe.

Ich wollte zwar nicht so schnell Rev 13 herausgeben, aber es bietet sich an. Jetzt müsste die Exe auch aus dem Zip-File heraus gestartet werden können.
Kleiner Nebeneffekt: Kein Extraladen von der Festplatte, der Quelltext wird "eleganter" und man braucht keine 2.Datei.
Auf diese Idee hätte ich schon lange kommen können.

Beste Grüße
Mathematiker

Hallo,

das war mir zuvor auch passiert.
Das habe ich in meiner uplama auch geändert, aber nicht zur Anzeige gebracht.

Was ich noch anmerken möchte:
bei der Zeitmessung wird auch die Zeit für das Zeichnen gestoppt.
Lazarus macht das ewig langsam und bei einer Paintbox von bxh = 1907x947 dauert die Rechnerei mit Lazarus 0,172 Sekunden, aber die Ausgabe über eine Sekunde.

Meine Version rechnet scheinbar nur richtig von dy > dx ist.
Unter Lazarus werden auch die Daten in anderen Registern / oder Reihenfolge übergeben, denn er springt bei Faktor= 0 nicht zu


Gruß Horst

Hallo Horst_H,

Horst_H hat folgendes geschrieben :

Was ich noch anmerken möchte: bei der Zeitmessung wird auch die Zeit für das Zeichnen gestoppt.

Ich habe jetzt die Zeitmessung sofort nach der Berechnung durchgeführt und das Ergebnis ist richtig schön. Die Berechnung allein braucht unter Delphi weniger als 0,04 s.

Horst_H hat folgendes geschrieben :

Unter Lazarus werden auch die Daten in anderen Registern / oder Reihenfolge übergeben

Als Notlösung schlage ich als erste Zeilen

vor. Dann müsste es eigentlich funktionieren. Oder wir nutzen wieder die Delphi-Variante:

So groß war der Geschwindigkeitsgewinn durch Assembler auch nicht.
Ich werde Alles für Rev 14 berücksichtigen, die ich aber nicht gleich veröffentliche.

Beste Grüße
Mathematiker

Das wird ja immer besser.

Generell ist es m.E. sinnvoll, Daten / Funktionen usw. dann permanent einzubinden, wenn sie (nahezu) immer benötigt werden und tendenziell nicht allzu groß sind. Je "optionaler" sie sind und je größer ihre Datenmenge ist, desto eher ist eine Externalisierung (z.B. in DLL(s), aber eben auch reinen Datendateien) gerechtfertigt. Aber auch, ob sie von nur einem Programm benötigt werden oder als Ressource für mehrer dienen, ist ziemlich ausschlaggebend, denn Redundanz ist häßlich.

Beim Spielen mit dem Faktor (scheint eine integre Variable zu sein, wenn man einen negativen Wert eingibt, sieht es aus wie bei einem sehr großen positiven) probierte ich auch noch einen gebrochenen, also eine Fließkommazahl. Wird nach Druck auf "Darstellung" mit einer anscheinend nicht individuell programmierten Fehlermeldung moniert. Solcherart ungültige Eingaben kann man, sofern man akribisch, penibel, pedantisch ist (das sind doch die meisten von uns Programmierern) mit einem try abfangen.

Warum Dein Programm so sehr die Aufmerksamkeit vieler auf sich zieht und Du üppige Unterstützung genießt, während ich sogar bei meinem Flaggschiff überwiegend auf mich allein gestellt war, ist mir ein wenig rätselhaft und macht mich sogar im nachhinein noch ein wenig neidisch.

Ergänzung: Allmählich fange ich wohl an, Dein Programm zu "quälen". Jedenfalls vertragen sich Zoomen des Formulares nicht mit der Farbrotation, d.h., wenn man bei laufender Rotation zoomt, würgt man damit die Rotation ab.

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Beim Spielen mit dem Faktor (scheint eine integre Variable zu sein, wenn man einen negativen Wert eingibt, sieht es aus wie bei einem sehr großen positiven) probierte ich auch noch einen gebrochenen, also eine Fließkommazahl. Wird nach Druck auf "Darstellung" mit einer anscheinend nicht individuell programmierten Fehlermeldung moniert. Solcherart ungültige Eingaben kann man, sofern man akribisch, penibel, pedantisch ist (das sind doch die meisten von uns Programmierern) mit einem try abfangen.

Danke für den Hinweis, habe ich gleich geändert und außerdem noch negative Werte abgefangen.

Delphi-Laie hat folgendes geschrieben :

Warum Dein Programm so sehr die Aufmerksamkeit vieler auf sich zieht und Du üppige Unterstützung genießt, während ich sogar bei meinem Flaggschiff überwiegend auf mich allein gestellt war, ist mir ein wenig rätselhaft und macht mich sogar im nachhinein noch ein wenig neidisch.

Verstehe ich auch nicht, dennoch finde ich es schön. Vielleicht liegt es daran, dass die entstehenden Bilder merkwürdig und gleichzeitig schön sind.

Beste Grüße
Mathematiker

Hallo,

ich habe mal eine Variante mit getestet

Die Rechnerei dauert dadurch ewig, da die Rekursionstiefe bis zu doppelt so groß werden kann.
das hat aber auch einen besonderen Effekt, den man Faktor= 0 besonders gut sieht.
Normal:


und flexibel:


Zebbow und haedache eignen sich besonders, da benachbarte Farben extrem unterschiedlich sind.

Gruß Horst

Hallo Horst_H,

Horst_H hat folgendes geschrieben :

Hallo, ich habe mal eine Variante mit getestet ... Die Rechnerei dauert dadurch ewig, da die Rekursionstiefe bis zu doppelt so groß werden kann. das hat aber auch einen besonderen Effekt, den man Faktor= 0 besonders gut sieht.

Das sind interessante Gebilde, die dabei entstehen. Damit eröffnen sich viele Möglichkeiten, denn die Lage des Mittelpunktes (xm, ym) ist ja noch weiter veränderbar.
Zu testen wäre auch, wie sich das auf andere Faktoren > 0 auswirkt.
Mal sehen, ob ich noch weitere Farbpaletten zusammenstellen kann, vielleicht eine mit abwechselnd Weiß/Schwarz ...

Beste Grüße
Mathematiker

Oha, hier gehts wirklich Schlag auf Schlag

Bezüglich des CMOVNZ habe ich bis D7 herunter getestet, der das klaglos übersetzt. Ich hatte nicht erwartet, das noch ältere Compiler hier unterwegs sind Man könnte das CMOVNZ mit DB-Direktiven als Binärcode mit integrieren, aber ich glaube, wir lassen zugunsten der Lesbarkeit besser

Was die Unterläufe angeht: Negative Werte werden einfach mit dem höchstwertigen Bit=1 dargestellt. -1 in EAX sieht also aus wie MAXINT, ist nur eine Frage der Interpretation. Da am Ende ohnehin ein AND EAX,$000000FF gemacht wird, aus der -1 ($FFFFFFFF) also eine 255 wird, spielt das keine ernsthafte Rolle und das ganze funktioniert einwandfrei.

Hallo OlafSt,

OlafSt hat folgendes geschrieben :

Ich hatte nicht erwartet, das noch ältere Compiler hier unterwegs sind

Mein geliebtes Delphi 5 hat mir immer treue Dienste geleistet und da ich als Hobby-Programmierer nicht die Absicht habe, Datenbank- oder Netzanwendungen zu erstellen, werde ich es auch noch lange, lange, lange behalten. Solange, bis Microsoft dafür sorgt, dass 32 Bit-Anwendungen nicht mehr lauffähig sind.

OlafSt hat folgendes geschrieben :

Man könnte das CMOVNZ mit DB-Direktiven als Binärcode mit integrieren, aber ich glaube, wir lassen zugunsten der Lesbarkeit besser

Es klingt kompliziert und interessant!

OlafSt hat folgendes geschrieben :

Was die Unterläufe angeht: Negative Werte werden einfach mit dem höchstwertigen Bit=1 dargestellt. -1 in EAX sieht also aus wie MAXINT, ist nur eine Frage der Interpretation. Da am Ende ohnehin ein AND EAX,$000000FF gemacht wird, aus der -1 ($FFFFFFFF) also eine 255 wird, spielt das keine ernsthafte Rolle und das ganze funktioniert einwandfrei.

Danke für die Erklärung, wieder etwas gelernt. Ich muss bei meiner Routine dennoch mit dem bedingten Sprung jz bei negativen Werten reagieren, da diese dann 1 werden müssen.

Hallo Delphi-Laie

Delphi-Laie hat folgendes geschrieben :

Allmählich fange ich wohl an, Dein Programm zu "quälen". Jedenfalls vertragen sich Zoomen des Formulares nicht mit der Farbrotation, d.h., wenn man bei laufender Rotation zoomt, würgt man damit die Rotation ab.

Das ist kein Quälen. Es ist sogar gut. Damit kann ich alle Fehler entfernen. Und das habe ich auch bei diesem Problem gerade getan. Langsam wird es wohl Zeit für die Revision 14.

Beste Grüße
Mathematiker

Mathematiker hat folgendes geschrieben :

Mein geliebtes Delphi 5 hat mir immer treue Dienste geleistet und da ich als Hobby-Programmierer nicht die Absicht habe, Datenbank- oder Netzanwendungen zu erstellen, werde ich es auch noch lange, lange, lange behalten. Solange, bis Microsoft dafür sorgt, dass 32 Bit-Anwendungen nicht mehr lauffähig sind.

No offense. Wenn man mit Assembler arbeitet, muß man solche Dinge berücksichtigen, denn natürlich wachsen die Delphi-internen Assembler mit den CPUs mit. DXE2 kann schließlich auch SSE4.2, was D2010 noch unbekannt ist, von 64Bit mal ganz zu schweigen.

Zitat:

OlafSt hat folgendes geschrieben : Man könnte das CMOVNZ mit DB-Direktiven als Binärcode mit integrieren, aber ich glaube, wir lassen zugunsten der Lesbarkeit besser Es klingt kompliziert und interessant!

Ich habe nochmal genauer nachgeschlagen (die Befehlsreferenz von Intel ist >200MB als PDF, und das ist nur Menmonics A-N...) und CMOVxx ist untauglich für unsere Zwecke. CMOVxx kann nur mit Registern arbeiten, nicht mit direkten Werten. Wir müßten also erst eine 1 in ein Register packen und dann CMOVen:


Dann ist aber unsere Optimierung für die Katz und wir können das ganze auch so lassen. Ich sehe da auch auf den zweiten Blick keine ernste Möglichkeit, noch Luft aus der Laufzeit herauszulassen

Gnaa, ich wollte mich mit meinem eigenen C#-Problem befassen, und nu kleb ich wieder hier dran

Also ich muss schon sagen: Alle Achtung. Von mehr als 1 Sekunde (je nach Häufigkeit des Bildaufbaus) auf 0,016 s.

Das nennt man Optimierung!

Hallo,

etwas Offtopic:
wenn man das Mov EBX,1 weiter vorne erledigen kann, verschwindet dessen Laufzeit, weil es parallel auf der einzelnen CPU verarbeitet werden kann.
Irgendwie bekommen die ( Intel/AMD etc) es ja hin, 3 oder mehr Befehle parallel zu bearbeiten IPC = 3
Siehe mal mein alten AMD www.delphipraxis.net/1150448-post40.html 31 Befehle in 14 Takten oder hier 2,56 Befehle / Takt
www.entwickler-ecke....%E4hlen&start=37
Die neueren Intel-CPU's haben AMD schon weit abgehängt.
Ein Thread/CPU: Amd bei um die 1 und Intel rauf bis 1,65.Das sind gewaltige Unterschiede.
pcpartpicker.com/ben...single/overall-list/

@Tranx:
Zu den Sekunden sollte man CPU-Takte oder zumindest die CPU-Taktrate angeben.
Also 0.01478 s für 597*513 = 306261 Bildpunkte auf einem AMD X4 955 mit 3,2 Ghz getestet mit Lazarus1.0.1/FPC 2.6.0. ergibt 154,4 Takte pro Bildpunkt.
Delphi ist meist schneller.
Ein Bild mit 584x584 Bildpunkte braucht 156,3 Takte, obwohl dann keine Berechnung zu viel, während bei 597x513 Bildpunkten fast 30% mehr gerechnet wird.
Das ist ja das Fatale/die Crux, man rechnet mehr, spart sich aber Vergleiche, die bei falscher Vorhersage 20 Takte kosten ( auch hier ist Intel auf dem Weg zu 10 Takten )und damit mehr Zeit kosten als die eigentliche Berechnung.

Gruß Horst
P.S
Die Berechnung selbst ist gar nicht so viel schneller geworden, nur das Zeichnen wurde verlegt und statt die Bitmap selbst zu bearbeiten ein Feld bearbeitet.

OlafSt hat folgendes geschrieben :

Ich hatte nicht erwartet, das noch ältere Compiler hier unterwegs sind

Warum nicht ("erwartet" bzw. "hier unterwegs sind")?

Meine Profil ist fast schon mein (nicht nur Delphi-)Programm, allerdings haben bei mir auch Turbodelphi und XE2 ihren Stammplatz, diese aber nur bei Bedarf. Von XE3 muß ich mir erst mal eine Testversion besorgen, um auf dem neuesten Stand zu sein. XE2 in der ersten offiziellen Version war wirklich schlimm (eher noch Beta als Gamma). Etwas derart unausgegorenes erlebte ich weder bei den Delphi-/C++-IDEs noch überhaupt bei kommerziellen Programmen....

Traurig finde ich nur, daß man mit Delphi nicht für niedrige Versionen speichern kann (wie es viele Programme können), so daß ich Mathematikers Delphi-5-Datendateien (konkret natürlich die Formulardateien) nicht mit Delphi 4 lesen kann. Und Delphi 5 mir deshalb extra zu installieren habe ich keine Lust.

Mathematiker hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben : Allmählich fange ich wohl an, Dein Programm zu "quälen". Jedenfalls vertragen sich Zoomen des Formulares nicht mit der Farbrotation, d.h., wenn man bei laufender Rotation zoomt, würgt man damit die Rotation ab. Das ist kein Quälen. Es ist sogar gut. Damit kann ich alle Fehler entfernen. Und das habe ich auch bei diesem Problem gerade getan.

Mathematiker, das hat seinen Grund: In den 90er Jahren stellte ich jemandem ein selbstgeschriebenes Programm vor. Der erzählte mir von jemand anderem, der, wenn man ihm ein Programm vorstellte, als erstes folgendes machte: Er drückte mehrere Tasten der Tastatur, ja, er legte beide Hände darauf ab, um möglichst viele Tasten gleichzeitig zu treffen, und konnte meistens, nämlich dann, wenn das Programm daraufhin abstürzte, genüßlich resümieren: "Und was ist das?"

In der Tat konnte man DOS-Programmen, die nur oberflächliche Standardeingaberoutinen verpaßt bekamen, so den Garaus machen, unter Windows dürfte das hingegen kein Problem mehr sein. Seitdem bin ich bezüglich (eben auch fehlerhafter) Nutzereingaben sensibilisiert und ein Enthusiast ergonomischer (wie ich sie verstehe und empfinde) Programme. So muß ein Programm immer und überall, d.h. zu jeder Zeit und in jeder Sitation, auf Nutzereingaben vorbereitet sein, eben auch auf die falschen. Konsequenterweise "öffnet" man ein Programm nur in den Situationen, in denen diese gewünscht sind, für bestimmte Eingaben.