Hallo zusammen,

ich habe mal generellen Klärungsbedarf:
Welche Operationen darf man unten allen Platformen mit einem Bitmap im Thread machen ?

VCL:
Unter VCL verstehe ich das so das Kopieren, Malen über den Bitmap.Canvas im Thread generell möglich ist.
Lediglich das Übergeben an ein Control zum Anzeigen muss im UI-Thread passieren.

FMX:
Hier vermute ich mal das Bitmap.Canvas auch eines rein im Speicher angelegten Bitmaps schon mit UI zu tun hat.
Womöglich wegen des Canvas, der unter FMX in verschiedenen Ausführungen erscheint, je nach Plattform.

Ich würde gerne mal klären welche Operation grundsätzlich auf allen Platformen OK sind, und welche nicht:

zusammenfalten · markieren

Delphi-Quellcode:

---------------- UI-Komponente <-- zu ---> Speicher-Bitmap im Thread
01. Create --------# im Thread bmpThread.Create(100, 100); ---- Ok: VCL-Ja, Fmx-?
02. Clear ---------# im Thread bmpThread.Clear(0); ------------ Ok: VCL-Ja, Fmx-?
03. Bearbeiten ----# im Thread bmpThread.Canvas.Draw... ------- Ok: VCL-Ja, Fmx-? -mit oder ohne Map/UnMap ?
04. Kopieren ------# im Thread bmpThread.Assign( bmpThread2); - Ok: VCL-Ja, Fmx-?
05. Filelesen -----> im Thread bmpThread.LoadFromFile(); ------ ??
06. Fileschreiben -> im Thread bmpThread.SaveToFile(); -------- ??
07. Streamlesen ---> im Thread bmpThread.LoadFromStream(); ---- ??
08. Streamschreib. > im Thread bmpThread.SaveToStream(); ------ ??
09. Assign --------> im Thread bmpThread.Assign( bmpUI ); ----- Nicht OK, muss syncronisiert werden
10. Zurückgeben ---< im Thread bmpUI.Assign( bmpThread ); ----- Nicht OK, muss syncronisiert werden

Habe ich was vergessen, kann man was ergänzen ?
Wie verhält sich das unter Fmx, so das es optimal unter allen Platformen läuft ?

Ich würde gerne alles bis auf 09/10 im Thread ohne grosse Verrenkungen benutzen, ist das denkbar ?

Vielleicht könnte man eine TBitmapThreadSafe Klasse bauen, das dies alles möglichst kapseln würde wenn man die
im Thread benutzt ?

Wäre schön wenn sich damit jemand auskennen und mir auf die Sprünge helfen könnte.

Rollo

Der Zugriff auf den Canvas bringt das non-thread-safe.

Die TBitmap Klasse ist nur für die Verwendung im MainThread gedacht gewesen und sollte daher auch nur in diesem Kontext verwendet werden.

Wenn jemand das anders verwendet und es funktioniert, dann diese Code-Zeilen in das Nachgebet einschliessen (auf das es weiter funktioniert). Zugesichert wird die Funktion in keiner Weise.

Das stimmt für die VCL, und dann auch nur bei Zugriffen über Canvas. So lange ich via Scanline in einem TBitmap rumfuchtel sollte alles okay sein.

Aber: Ist das bei FMX noch genau so? Ich weiss es mangels Delphi-Version mit FMX nicht*, aber FMX arbeitet gerade beim Thema Grafik explizit nicht mit der WinAPI, welche die Schnittstelle zum Canvas bereitstellt. Von daher kann hier alles anders aussehen. Eine offizielle oder zumindest gut informierte und begründete Aussage wäre da in der Tat wünschenswert.

*) Und ich bin bei Bitmaps komplett auf die Graphics32 umgestiegen, welche in Threads keinerlei Probleme bereitet.

Zitat von Marco Cantu:

In general, bitmap operations in background threads have never been allowed, although they do occasionally work.

Quelle http://community.embarcadero.com/for...working-in-xe8

Remmy Lebeau hat es mal bezogen auf das VCL-TBitmap zutreffend so beschrieben:

"Technically, nothing about it is thread-safe. You should always provide a
lock around multi-threaded access to shared resources. But as long as
neither bitmap is ever being resized or having its underlying handles
regenerated, in other thread while you are reading the Scanline[property] or
modifying its contents, then you should be ok."

Bei FMX ist es im Prinzip ähnlich, Bitmap / Canvas ist auch nicht Threadsafe, das oben gesagte gilt aber auch hier.

Zusätzlich helfen Dir aber BeginScene und Endscene die Zugriffe auf den Canvas Kollisionsfrei hinzubekommen (viele nutzen allerdings Beginscene quasi als Procedur-Aufruf und werten das Ergebnis nicht aus) bzw. Map und Unmap beim Zugriff auf die Pixeldaten des Bitmaps.

Insofern macht so eine Auflistung hier m.E., wenig Sinn, hängt alles vom Kontext Deines Threads bzw. der evtl. gemeinsam benutzten Ressourcen ab.

Ja, ach. Ole ole. Dass man ein und dieselbe Ressource nicht in 2 Threads gleichzeitig verändern darf ist jetzt aber auch nicht gerade eine exklusive Domäne von TBitmap, oder? Das selbe gilt ebenso für TList, Arrays, und jeden anderen Typen, bei dem Manipulation nicht in atomaren Operationen geschieht, bzw. wo Referenzen existieren die ggf. bei "fremden" Akteuren nachgeführt werden müssen.
Bei Bitmaps kommt (unter Win32 zumindest!) lediglich dazu, dass hier u.U. Handles vom OS geändert werden, die ein Thread möööglicherweise mal irgendwo gepuffert hat. (Lies: Ich übergebe einem Thread ein HBITMAP oder einen Canvas-Handle statt der Referenz auf das TBitmap-Objekt.) Aber genau diese 2 Dinge existieren unter FMX möglicherweise gar nicht.
Diese Quellen alleine sind grob simplifizierend, und wenden eine eigentlich sehr allgemeine Regel unberechtigt spezifisch auf TBitmap an. Dass man bei Threads und gemeinsamem Zugriff auf was auch immer eine Form von Synchronisation braucht sollte wohl jedem klar sein, der Threads 2-3 Mal in der Hand hatte. Spätestens.