TBitmap ist NICHT threadsave

[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.

[Sir Rufo]

Zitat von 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.

Wieso das denn jetzt?

Mir war eigentlich schon immer bewusst, dass alles was mit VCL zu tun hat nicht threadsafe ist. Analog gilt das auch für FMX.

Wenn man nicht weiß, wozu die Klasse XY nun gehört, dann schaut man sich den Namespace an und weiß sofort, wo man kein threadsafe erwarten kann

Delphi-Quellcode:

Vcl.Graphics.TBitmap // <- Vcl davor => NEIN
FMX.Graphics.TBitmap // <- FMX davor => NEIN

Prinzipiell ist eigentlich alles erst einmal als nicht threadsafe anzusehen. Die Dokumentation sollte es explizit hervorheben was threadsafe ist und nicht umgekehrt, sonst sieht man vor lauter nicht threadsafe den Thread nicht mehr.

VCL und FMX sind zudem immer noch als MainThread-Affin anzusehen (darum geht es hier eigentlich und nicht um threadsafe)

[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.

[Bernhard Geyer]

Zitat von 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.

Das Problem ist die wechsel des Threads und hier das Hauptproblem auf MS/Windows-Seite.
Alle GUI-Ressourcen von Windows sind nur im erzeugenden Thread gültig.
D.h. wenn du dein Bitmap nur in einem Thread erzeugst, bearbeitest und freigibst ist alles gut.
Damit hat auch die VCL kein Problem da hier keine weiteren Abhängigkeiten zu Formular, Screen und Co. existiert.

[bernau]

Zitat von Bernhard Geyer:

Alle GUI-Ressourcen von Windows sind nur im erzeugenden Thread gültig.
D.h. wenn du dein Bitmap nur in einem Thread erzeugst, bearbeitest und freigibst ist alles gut.

Und das ist es anscheinend nicht.

[himitsu]

Kämpf dich doch mal durch den Code von TBitmap,
also vorallem wo das Canvas her kommt und speziell die darin vorhandenen TPen oder TBrush.

Da landet man z.B. beim TResourceManager, der die Resourcen threadabhängig verwaltet.

[Kraisel]

Hallo Zusammen,

OK, ... scheint also doch immer noch ein kleines Problem mit sehr unterschiedlichen Erfahrungen zu sein.

Wie ich schon sagte, ist mir seit den Anfängen von Delphi klar, dass vieles in der VCL bzw. in FMX NICHT threadsave ist. Und es ist auch richtig, dass man grundsätzlich unterstellen sollte, dass alles, was man benutzt, vielleicht NICHT threadsave ist.

Ich hatte aber gehofft, dass ich in einem Thread eine FMX-Bitmap mit Map öffnen kann und dann selber Pixel lesen und/oder manipulieren kann. Aber selbst das geht eben in 1..10 % der Fälle schief und man merkt es nicht, da evtl. nur einige Pixel falsch sind. Das hatte ich einfach nicht erwartet.

Wohlgemerkt, ein Synchronize über den Bmp-Methoden im Thread und alles ist wieder gut. Deshalb gehe ich auch davon aus, dass mein Test OK ist, was man natürlich auch noch hinterfragen kann.

Wie Harry vorgeschlagen hat, werde ich deshalb, wenn ich Zeit habe, meinen Test aus meinem Framework separieren und hier hochladen. Das kann aber etwas dauern, da ich wie 'immer' unter Zeitmangel leide.

[Sir Rufo]

Es gibt einen Unterschied zwischen threadsafe und threadaffin. Die meisten Klassen sind nicht threadsafe aber - gottlob - auch nicht threadaffin.

• threadsafe
  Von jedem Thread kann auf die Eigenschaften der Klasse zugegriffen werden.
• threadaffin
  Auf die Eigenschaften der Klasse darf nur im Erzeuger-Thread zugegriffen werden
• ganz blöd
  Die Klasse ist noch mit einem globalen (oder wie auch immer aufgehängtem) Kontext verwoben, der auch noch threadaffin ist (idR. mit dem MainThread)

TBitmap gehört eindeutig zur Kategorie ganz blöd.

Wenn jemand so etwas in einem Thread verwendet und keine Probleme damit hat, dann jeden Abend das in das Nachtgebet mit einschliessen und weiter hoffen. Es ist keine zugesicherte Eigenschaft und läuft wohl eher durch Zufall (oder man hat sich irgendwo durch die Hintertür eine Synchronisation eingefangen). Anyway, empfehlen würde ich es nicht und darauf bauen erst recht nicht.

Aber eine Hummel kann eigentlich auch nicht fliegen und tut es trotzdem, weil ihr die Physik und Aerodynamik fremd und sowas von egal sind.

[Rollo62]

Zitat:

D.h. wenn du dein Bitmap nur in einem Thread erzeugst, bearbeitest und freigibst ist alles gut.

Zitat:

wo das Canvas her kommt

Könnte es sein das Beides stimmt ?

Wenn man nur das BMP im Speicher anlegt und über Scanline auf die Pixel zugreift ist es im Thread machbar,
sobald ein Canvas oder was anderes in Spiel kommt ist es MainThread affin ?

Ich halte es so das ich nur im Mainthread drauf zugreife, weil mir diese Aussagen auch nicht 100% sicher sind.

Rollo