Hmmm ... hier arbeiten aber doch eigentlich keine 2 (oder mehr) Fredl's gegeneinander.
Diese
Unit wird in einem CallBack getriggert, eingehende Daten in einen eigenen Puffer kopiert.
Danach gehts gleich zurück zum Caller - zuvor wird noch der Auswerte-Thread gestartet, der die Daten zwecks Inkonsistenz aus dem internen Puffer liest.
Und wie gesagt: So lange der Thread arbeitet (interne Kontrollvariable) werden keine neuen Daten in der CallBack-Methode akzeptiert.
Kann zu minimalem Datenverlust, bzw. erneutem warten darauf resultieren, ist aber noch nicht vorgekommen - also nicht das (Zeit-) Problem.
D.h., der Thread arbeitet stur seine Daten ab und zeigt die (normalerweise) auch nach Auswertung korrekt an.
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.
"ThreadSafe" muss die OSD-Form doch gar nicht, sein weil keine weiteren Fredi'S (gleichzeitig) zugreifen.
Der Thread ist ledigliglich dazu gedacht, nicht ggf. den aufruferenden Dispatcher des DS-Filters zu blockieren um nicht den Daten-Strom des restlichen Direkt-Show-Systems zu blockieren.
Diese Funktionsweise ist schon seit Jahren hier getestet und läuft ansonsten tadellos.
Hab ich da einen eklatanten Denkfehler ?
Absolut unverständlich ist mir, warum es mit einem TImage mehr oder weniger gut funzt, mit direktem Schreiben auf's Canvas der Form oder dem TImage nicht.