Du weißt dass weder VCL-Zugriffe noch TCanvas threadsave sind?

Deshalb war der Gedanke für jeden Thread unterschiedliche Bitmaps zu verwenden. Das sie nicht Threadsave sind habe ich in der Hilfe gelesen.

Also Thread 1 bekommt screen1 und search1 und thread 2 bekommt screen2 und search2. Somit sollten sich die Canvas doch nicht ins Gehege kommen oder sehe ich das falsch ?

Grüße
s0n

Leider ist dem nicht so. Ich habe mal ein Microdemo angehängt bei dem ein paar Bitmaps parallel erzeugt `bemalt` und gespeichert werden (Pfad anpassen). Wenn man sich das Ergebnis ansieht wird klar dass Canvas nicht Threadsave ist. Über lock ließe sich das ganze verhindern, aber dann ist der Gewinn durch die Threads ebenfalls weg. Ich weiß ja nicht was genau der Vergleich machen soll, aber über Scanlines (wenn Dir das hilft) sollte es keine Probleme geben.

TBitmap und Co. wären Threadsave, wenn sie "unabhängig" verwendet werden und nichts Globales nutzen.

Aber sie verwenden intern weitere Klasseninstanten und da werden vorallen für TFont, TBrush uvm. globale Instanzen verwendet (wenn man selber nichts eigenes angibt und die Werte auf "Standard" läßt)
und da dort überall auf die selben globalen Singletons zugegrifen wird muß es zwangsläufig schief gehn, jenachdem was man mit dem Bitmap macht.



Was man machen kann, das Bitmap für die VCL blocken, wenn es z.B. in einem TPicture steckt oder sonstwie angezeigt wird,
im Hauptthread sich den Anfang der Daten (ScanLine der letzen Zeile) besorgt und im thread nur "direkt" selber darin rummalt.

Wenn man das Bild nur aufteilt, dann kann es ja auch passieren das sich der gesuchte Bereich in keinem Bild mehr befindet.

Bild:
111111
222222
333333
444444
555555
666666

Aufteilen in 2 Bilder:
111111
222222
333333

444444
555555
666666

Suche nach dem Bereich:
33
44

Habe ich mir zumindest beim Lesen so überlegt...

Mal abgesehen von der Threadproblematik von VCL-Klassen...

Vorschlag:

1. Umwandeln des zu durchsuchenden Bildes in die Daten (GetBitmapBits) - auf diese Daten können alle Threads lesend zugreifen.
2. Umwandeln des/der zu suchenden Ausschnitts/e in die Daten
3. Daten selbst vergleichen (die korrekten Indices zu bestimmen, ist keine Doktorarbeit)
4. Für Thread-Aufteilung lässt sich das Bild(1) in horizontale Streifen aufteilen, die jeweils von einem Thread durchsucht werden können (der Thread beginnt mit jedem Punkt innerhalb des Streifens, der "ObenLinks" des Ausschnitts sein könnte).
5. Die Ergebnisse werden entweder per "PostMessage" oder per Rückruffunktion an den Aufrufer zurückgemeldet.

Erst einmal danke für die ganzen Hinweise. Danke für das snippet ...

danke an Mikkey für die Tipps .. werde mich rantasten und rumprobieren. Wenn ich hängen bleibe habe ich ja euch ^^

Danke nochmals für die Tips

Grüße s0n

Zitat von user0815:

Wenn man das Bild nur aufteilt, dann kann es ja auch passieren das sich der gesuchte Bereich in keinem Bild mehr befindet.

Bild:
111111
222222
333333
444444
555555
666666

Aufteilen in 2 Bilder:
111111
222222
333333

444444
555555
666666

Suche nach dem Bereich:
33
44

Habe ich mir zumindest beim Lesen so überlegt...

jepp das ist korrekt ,deshalb ist es ratsam sagen bei 100x100 das bild nicht in 2st. 50x100 zu teilen sondern um das suchbild größer
also 2St. 55x100 der so. sodass definitiv die Suche erfolgreich ist

Aber recht hast du. Habe ich noch gar nicht dran gedacht ;(

Zitat von sonny2007:

jepp das ist korrekt ,deshalb ist es ratsam sagen bei 100x100 das bild nicht in 2st. 50x100 zu teilen sondern um das suchbild größer
also 2St. 55x100 der so. sodass definitiv die Suche erfolgreich ist

Aber recht hast du. Habe ich noch gar nicht dran gedacht ;(

.. auch das wird nit zu einer 100% Trefferquote führen.
Denn es kann immer noch sein, dass der gesuchte Bildauschnitt auf der Schnittkante der beiden Bilder sich befinden.

Meiner Meinung nach müssen bei einer zweiteilung des Bildes 3 Suchabschnitte durchgeführt werden.

1. 00..50 (erster Bildteil)
2. 51..99 (zweiter Bildteil)
3. 25..75 (Schnittmenge, abhänging von der Größe des gesuchten Bildauschnitts)

Grüße
Klaus

Zitat von sonny2007:

Zitat von Blup:

Mal abgesehen von der falschen Verwendung von Threads...

Das Kopieren eines Ausschnitts der ScreenBMP in die tempBmp ist hier der eigentlich bremsende Faktor.
Es erscheint mir sinnvoller die Funktion "Compare2Bitmaps" so anzupassen, dass statt zwei kompletter Bitmaps, nur der angegebene Bereich verglichen wird.

Compare2Bitmaps(80, SearchBMP, ScreenBMP, rectSource);

ich kopiere in die TempBmp einen Ausschnitt des Screens und nur der wird mit dem Suchbitmap verglichen. Verstehe jetzt nicht so ganz wie du es meinst.
Bin für Kritik und Verbesserung jederzeit zu haben ^^

Grüße s0n

Du versuchst die Geschwindigkeit zu verdoppeln in dem die Arbeit auf 2 Threads verteilt wird. Der eigentliche Zeitfresser ist aber das ständige Kopieren der ScreenBMP in die TempBMP. Wenn man dies vermeiden könnte, lies sich die Geschwindigkeit vermutlich vervielfachen, ohne mit Threads zu arbeiten. Dazu müsste halt lediglich die Funktion Compare2Bitmaps angepasst werden. Das sollte relativ einfach möglich sein, aber dafür bräuchte diese Funktion dann statt der TempBMP, die ScreenBMP und das Recheck für den Vergleich.