Hi,
@Andidreas Sorry aber als etwas Aussenstehender finde ich deine Kritik, dass du doch nach weiteren Lösungen fragen kannst etwas nun ja. Natürlich kannst du immer nach weiteren Lösungen fragen, bis dir eine gefällt aber ich denke dass wäre doch irgendwie etwas ignorant. Ich denke das was Luckie sagte war nicht böse gemeint (hast du hoffentlich auch nicht so aufgefasst), aber letztlich sagt er ja nur, dass du da zwei Möglichkeiten hast.
Das du noch nicht mit Threads gearbeitet hast ist ja ok, aber du sagst nirgends, warum das jetzt ein Problem ist. Ich meine du wirst wahrscheinlich mit mehr Techniken nicht gearbeitet haben als umgekehrt, geht doch den meisten so. Aber wenn du eine Technik nicht kennst, dann such doch einfach ein wenig was dazu, zu Threads z.B. in der
DP 
Ich meine das nicht böse, ich persönlich fand nur deine Reaktion etwas weit hergeholt.
Was Threads angeht, so ist es recht einfach mit ihnen zu arbeiten. Das gilt überhaupt nicht pauschal, aber für dein Problem. Die Grundlagen liegen allerdings auch hier im Beitrag von xaromz, der sagte ja schon, dass Windows deine Rechenzeit verwaltet. Kein Prozess weiß, wieviel CPU Zeit es bekommt (es denkt immer es hätte 100% CPU Zeit, 100% vom Speicher und sei das Einzigste Programm auf der Welt). Für Threads gilt eigentlich das Selbe (beides ist stark vereinfacht). Jedenfalls schaltet Windows ganz ganz schnell zwischen einzelnen Programmen und Threads hin und her. Ein Programm hat dann immer für eine gewisse Zeit (die das Programm nicht kennt) die CPU und den Speicher. Läuft die Zeit ab, speichert Windows den Zustand und kopiert den zurück, bevor das Programm das nächste mal dran ist.
Hier hast du dann jetzt die Möglichen Probleme beim Threading, laufen zwei Threads parallel, so weißt du nicht wo sich welcher Thread wann befindet. Greifen beide auf ihren Speicher zu, ist das kein Problem. Teilen sie sich aber irgendeinen Bereich, so kann es hier zu Konflikten kommen. Ein Beispiel wäre eine Bank. Sagen wir du hast einen Thread, der etwas abbucht und einen der etwas gutschreibt. Sagen wir noch auf deinem Konto sind gerade 1000 Euro. Der eine Thread möchte 500 Euro gutschreiben, der andere möchte 1000 abbuchen. Die einzelnen Schritte sehen ungefähr so aus:
- Hol dir den aktuellen Kontostand
- Schreib Betrag gut / zieh Betrag ab
- Speicher Kontostand
So, mit nur einem Thread würde es so aussehen, dass du erst (reihenfolge eigentlich egal) 500 Euro bekommst und dann 1000 abgezogen werden, du hättest also noch 500 Euro auf deinem Konto.
Beim Threading laufen beide Prozesse gleichzeitig. Es kann nach jedem der drei Schritte zur Ausführung des jeweils anderen Thread kommen. Ein Problem wäre, wenn sich beide gleichzeitig den alten Kontostand holen (1000 Euro), dann beide den Betrag gutschreiben/abziehen und nun kommt es drauf an, wer zuerst speichert. Wird erst der abgezogene Betrag gespeichert, wäre der letzte Stand der gespeichert wird 1500 Euro (+), gut für dich schlecht für deine Bank. Andersrum würde es aber zu 0 Euro führen (schlecht für dich! und die Bank hätte Geld verloren, auch nicht gut).
Solange du aber einen Thread die eigentliche Arbeit sequentiell machen lässt (er also als einziger auf seinen Daten arbeitet), kann dir das alles egal sein. Da wird der Thread halt als neuer Prozess nebenbei gestartet (und es kommt nie zu einem Konflikt). Wie man das genau macht, entnimmst du am besten einem Tutorial zum Thema Threads oder schaust in die
OH. TThread heißt hier das Schlüsselwort.
Was die Zeit angeht, die dein Programm verbraucht, es klingt einfach langsam, da du nur 2,5 MByte an Daten verarbeist. Schau dir einfach mal an, in welcher Zeit ein Grafikprogramm Dateien von >> 10 MByte verarbeitet. Da werden wenige Milisekunden benötigt. Du siehst da schnell warum es langsam wirkt (muss ja nicht so sein).
Gruß Der Unwissende
[EDIT]
Was ProcessMessages angeht, so stimmt das natürlich, was gesagt wurde. Aber Application.ProcessMessages ist ein schlechter Weg. Der Aufruf dieser Methode kostet Zeit, auch wenn mal nichts zu tun ist. Andererseits wird auf Nachrichten (wie dem neu zeichnen) nur reagiert, wenn die Windowsbotschaft dafür auch behandelt werden kann. Man muss also einen Kompromiss zwischen sehr vielen Application.ProcessMessages (sehr langsam) und sehr wenigen (seltenes Neuzeichnen) finden.
Wird ein Thread mit niedrigerer Priorität verwendet, so bekommt der immer die volle Rechenzeit, die zur Verfügung steht. Muss das Fenster neu gezeichnet werden, wird die durch die Applikation höherer Priorität ausgelöst. Dieser Prozess würde dann automatisch Vorrang bekommen. Somit muss man sich keine Gedanken um die Stellen machen, an denen man ein Neuzeichnen erlauben möchte, es passiert automatisch dann und nur dann, wenn es nötig wird.
[/EDIT]