TBitmap ist NICHT threadsave

[Kraisel]

Hallo Zusammen,

dies ist keine Frage, sondern nur eine getestete Aussage. Denn immer mal wieder tritt die Frage auf, ob TBitmap threadsave ist oder nicht. Wie viele andere Kollegen auch, war ich der Meinung, dass man durchaus mit Map/Unmap in einem Thread wenigstens aus der Bmp lesen kann. Aber selbst das geht manchmal schief und es werden falsche Pixel gelesen. Ob hier ein falscher Buffer zurückgegeben wird oder ob die Inhalte nicht stimmen, habe ich nicht weiter untersucht.

Hier die getestete Antwort:

TBitmap ist NICHT threadsave. (getestet mit XE10.1 Berlin und FMX.)

Das Böse daran ist, dass man vieles nicht merkt, aber die Bilder sehen u.U. im Thread anders aus als gezeichnet.

Testaufbau:

1) Es werden im Mainthread eine zufällige BmpSize, 100 zufällige Koordinaten, 100 zufällige Farben, 100 zufällige Opacities usw. in einen Buffer geschrieben.
2) Eine Methode BmpBuilder baut eine Bmp mit dem Inhalt dieses Buffers, z.B. 100 Linien mit 100 verschiedenen Farben, die ja vorher per Zufall bestimmt wurden.
3) Im MainThread wird eine Bmp Referenz mit dem BmpBuilder generiert.
4) In 6 TTasks wird je eine eigene Bmp mit demselben BmpBuilder generiert.
5) Dann werden die Bmps im Mainthread oder auch in der Task mit der Referenz Pixelweise verglichen.
6) Dann beginnt alles wieder mit Schritt 1 mit neuen zufälligen Werten.

Ergebnisse:

Mit Synchronize im BmpBuilder: eine Fehler erkennbar, auch nach Stunden und Millionen Bmp Vergleichen festgestellt.

Ohne Synchronize:, also TBitmap-Methoden direkt im Thread bemutzt:
Schneller Absturz bei Benutzung von z.B. TextWidth, TextHeight und FillText. OK, ... das bekommt man ja mit.

Aber folgendes bekommt man nicht mit:

z.B. die Canvas-Methoden Begin/EndScene, Map/Unmap, DrawLine und einige mehr, stürzen nicht ab, aber die generierte Bmp
zeigt zufällige Fehler im Bild mit einer Wahrscheinlichkeit von 1..10% der getesteten Bmps (mehrfach mehrere Millionen Bmps getestet)?

Nicht weiter untersucht, da ausreichend fuer die Beurteilung, dass alle TBitmap-Methoden nur im Mainthread benutzt werden sollten.

[Bernhard Geyer]

TBitmap verwendet Windows-Ressourcen.
Und diese sind per Defintion Thread-Affine und sind nur im erzeugenden Thread gültig

[Kraisel]

Unter FMX (Firemonkey) kann man nicht unbedingt von Windows-Resourcen ausgehen.

[Bernhard Geyer]

Zitat von Kraisel:

Unter FMX (Firemonkey) kann man nicht unbedingt von Windows-Resourcen ausgehen.

Wenns unter Windows läuft vermutlich schon (auch wenn ich die Details der FMX-Implementierung nicht kenne)

[Sir Rufo]

Die Aussage von Marco Cantu dazu lautet "TBitmap ist niemals für die Verwendung ausserhalb des MainThreads gedacht gewesen." (egal ob VCL/FMX).

Von daher ist diese Erkenntnis nicht wirklich neu oder überraschend.

[Der schöne Günther]

Zitat von Sir Rufo:

Die Aussage von Marco Cantu dazu lautet "TBitmap ist niemals für die Verwendung ausserhalb des MainThreads gedacht gewesen." (egal ob VCL/FMX).

Von daher ist diese Erkenntnis nicht wirklich neu oder überraschend.

Vorausgesetzt man geht davon aus dass die offizielle Doku nicht reicht und man zusätzlich immer Community-Foren, Twitter, Google und sonstwas-Accounts von bestimmten Leuten folgen muss um die Bibliotheken fehlerfrei verwenden zu können.

[Delphi-Laie]

Zitat von Sir Rufo:

Die Aussage von Marco Cantu dazu lautet "TBitmap ist niemals für die Verwendung ausserhalb des MainThreads gedacht gewesen." (egal ob VCL/FMX).

In meinem Sortierkino läuft TBitmap in Extra-, also Nicht-VCL- bzw. Nichtmainthreads wie gewünscht.

[Harry Stahl]

Hallo Peter,

kannst Du Deine Testroutine hier mal hochladen?

Würde es gerne selber mal nachvollziehen.

[himitsu]

TBitMap und vorallem dessen TCanvas verwenden globale Instanzen von verschiedenen Delphiressourcen,
wie z.B. Fonts, Brushs, Pens usw.

Das kann also nicht so einfach Threadsave werden, so lange noch irgendwo auf etwas Globales zugriffen wird.



Abgesehn davon, daß in Windows GDI-Ressourcen an den erstellenden Thread gebunden sind.