Bitmap.Canvas -> Form.Canvas ... nix zu sehen

[TERWI]

Sorry, wenn es so erscheint, als wenn ich mich (bewusst oder absolut) dumm stelle ...

Wie ist den bitte "threadsicher" (genau !) definiert ?
Meiner Erkenntnis nach gilt das für den Fall, wenn (in einer Form, Unit, Methode, ...) der zeitgleiche oder auch zeit-überschreibende Zugriff auf "den selben" Datenbereich (oder Methode ?!) verhindert wird.
Gilt für lesen wie scheiben !?

Meine Form-OSD bekommt hier aber immer nur einen "Ping" von immer dem gleichen Aufrufer immer der Reihe nach. Da überschneidet sich nix. Keine weiteren Anfragen/Aufgaben anderen Threads.
Wo ist da ein Thread-Problem betreff Sicherheit ???

Bitte erkärt's mir.

[himitsu]

Zitat:

Zitat von TERWI (Beitrag 1406951)

Wie ist den bitte "threadsicher" (genau !) definiert ?

thread safety
Per se so, dass nur ein Thread gleichzeitig damit etwas machen darf.
Viele Komponenten verwenden aber auch globale Dinge (z.B. Default-Instanzen für Brush, Pen, Font usw.), welche auch von der Form und anderen Komponenten immer wieder zum Malen genutzzt werden ... aus dem Hauptthread heraus.

thread affinity
Bezüglich GDI+ und Dergleichen, auf welchem die VCL basiert, da dürfen/können viele Dinge nur in dem Thread verwendet werden, in welchem sie erstellt wurden.
https://blogs.msdn.microsoft.com/old...13-11/?p=33783

[jaenicke]

Eine mögliche Lösung ist ein HBitmap zu verwenden und das nur in die eine oder andere TBitmap Instanz einzukoppeln. Sprich HBitmap im Thread erzeugen, an Handle einer TBitmap Instanz zuweisen, darauf zeichnen und dann nur das Handle weitergeben. Dieses Handle kann man dann im Hauptthread wieder in ein TBitmap werfen um damit zu arbeiten.

Soweit ich weiß ist das vollkommen in Ordnung dieses HBitmap in mehreren Threads weiterzureichen solange nur ein DC darauf aktiv ist. Solange keine parallelen Zugriffe erfolgen, das also ggf. gesichert wird, soweit ich weiß auch mehrere DC.

Alternativ kann man natürlich auch nur mit der API, HBitmap und DCs arbeiten, das sollte meines Wissens immer in Threads gehen solange keine parallelen Zeichenzugriffe erfolgen.

Aber das alles ist schon eine Weile her, ich würde das zur Sicherheit noch einmal nachlesen... :wink:

[TERWI]

Jetzt bin ich etwas verwirrt (überfordert...)
Hier mal auszugsweise die CREATE der besagten Unit:

Delphi-Quellcode:

constructor TDATA2.Create();
begin
  inherited Create;
  ...
  FParserThread := TParserThread.Create(Self); 
  FParserThread.SuspendWork;
  FParserThread.Resume;
  ...
  FFont            := TFont.Create;
  FFont.Name       := 'Lucida Console';
  FFont.Size       := 16;
  FFont.Style      := [fsBold];
  FFont.Color      := clWhite;
  ...
  FBMOSD                    := TBitMap.Create;
  FBMOSD.PixelFormat        := pf32bit;
  FBMOSD.Canvas.Brush.Color := clBlack;
  FBMOSD.Canvas.Font.Assign(FFont);
  FTextHeight               := FBMOSD.Canvas.TextHeight('X');
  FTextWidth                := FBMOSD.Canvas.TextWidth('X');
  FBitmapWidth              := FTextWidth * 40;
  FBitmapHeight             := FTextHeight * 25;
  FBMOSD.Width              := FBitmapWidth;
  FBMOSD.Height             := FBitmapHeight;
  _FillRect(0, 0, FBitmapWidth, FBitmapHeight, clBlack);
  ...
end;

Zur Erinnerung:
FBMOSD wird NICHT im HauptThread oder von sonstigen Threads verwurstet, sondern lediglich in einer (zuvor jedoch IM Hauptthread erzeugten) separaten OSD-Form - extra nur (hilsfsweise) für diese Unit.
Hilft das weiter ?

[jaenicke]

In welchem Threadkontext wird denn auf die Bitmap gezeichnet? Das ist im Grunde die einzige Stelle, die wir noch nicht konkret gesehen haben. Aber das ist genau entscheidend.

Im Zweifelsfall genügt ein Stacktrace, wenn du an der Stelle einen Haltepunkt setzt und anhältst.

TData2.Create wird ja noch deinen Ausführungen im Hauptthread aufgerufen, oder?

[TERWI]

Siehe #26.

[KodeZwerg]

Hab mich vertan, tut mir leid für msg.

[jaenicke]

Zitat:

Zitat von TERWI (Beitrag 1406960)

Siehe #26.

Dort verstehe ich es so als ob der Thread durchaus mit der Ausgabe und sogar einem VCL-Formular zu tun hat:

Zitat:

Zitat von TERWI (Beitrag 1406946)

Auch die OSD-Form (hier hilfweise als extra Form) wird von nichts & niemand anderem als genau diesem Thread aufgerufen. M.E.n kann also auch da kein Konflikt auftreten.

Beides ist aber aus einem Thread heraus verboten.

Ich habe nicht umsonst (mit wenig Resonanz leider) den Beginn einer Multithread-Komponentenbibliothek veröffentlicht, eben weil Threads und VCL nicht zusammen funktionieren:
https://github.com/jaenicke/MTCL

[TERWI]

Zitat:

Zitat von jaenicke (Beitrag 1406973)

...Beides ist aber aus einem Thread heraus verboten.

Gut, sei es einfach eben mal so.
Allerdings - siehe #20 - scheint es ja zu funktionieren. Auch

Delphi-Quellcode:

Image1.Picture.Assign(BitMap);

geht.
X andere Versuche mit Draw, CopyRect, BrushCopy auf (irgendein) Canvas funzen nicht, bzw. nur (sehr ) kurz.

Und:
Das Geflacker scheint offensichtlich eine ganz andere Ursache zu haben -> nämlich in der "Malerei" der Ursprungs-Bitmap, also FBMOSD.

Die Katze mal aus dem Sack gelassen:
Das ganze ist/wird ein DVB-Teletext-Parser, der etwas flotter, universeller mit ein paar extra Features sein soll.
Zur Zt. fliegen da noch etwa bis zu 20 BitMaps/s an die OSD, weil der Decoder noch nicht optimiert ist, bzw. noch Fehler im Detail stecken.
Durch Fehlinterpretation von Steuerzeichen kommt es daher unregelmäßig zu diesen "Flashes", wenn mit clWHite das BitMap gelöscht wird.
Ein Eigentor .....

Nun mal schauen, wie es mit dem schreiben der BM direkt in den Video-Renderer klappt, das richtige OSD also.

Vergessen:
Ich hab testweise den ParserThread rausgenommen, nun läuft alles "straight" aus der OnTSReceive Methode.
Effekt: (Erwartungsgemäß) Genau das gleiche Geflacker wie mit Parser.
Es lieht also nicht am Thread.

[jaenicke]

Das Flackern liegt an der Art zu zeichnen. Wenn du TImage benutzt, wirst du das auch nicht wegbekommen. Das geht wirklich nur indem du im OnPaint selbst zeichnest. Damit lässt sich das weitgehend unter Kontrolle bekommen.

Viel sinnvoller wäre aber eine hardwarebeschleunigte Herangehensweise. Dann ist das ganze nicht so CPU lastig und flackert auch nicht. Delphi 2009 bietet da allerdings leider noch nichts direkt, da brauchst du externe Bibliotheken.