Threadübergreifende Bitmap

[Der schöne Günther]

Ich habe selber auch grade so etwas probiert, bekomme ständig "Out of resources". Siehe auch hier:
http://www.delphipraxis.net/108000-t...tml#post735086

Ohne im Quelltext zu wühlen, dafür aber die Suchmaschine meines Vertrauens zu befragen, sieht es (zumindest für Laien wie mich) wirklich danach aus, als könnte man mit Vcl.Graphics.TBitmap nur im Hauptthread arbeiten?

[Bernhard Geyer]

Zitat von FirstTry:

Habe den Link gefunden

Code:

http://www.snehovapohotovost.cz/authorsmore.php?id=6929

Also liegt der Fehler in der Verarbeitung von WindowsHandles?
Es kann doch nicht sein, dass mein Fehler nicht "normal" lösbar ist... Sicher dass es am Bitmap liegt?
Könnte es anstatt mit Synchronize mit irgendetwas anderem klappen?

Es ist meine Vermutung das es hieran liegt. Und wenn es daran liegt dann muss man halt den (aufwändigeren) Weg gehen und keine Win32-GDI-Ressourcen über Threadgrenzen hinweg zu verwenden.

[Dejan Vu]

Also ich habe in die While-not-terminated-Schleife ein Sleep eingebaut und die Instantiierung des Bitmaps in den Konstruktor des Threads verlagert. Klappt.

[Bernhard Geyer]

Zitat von Dejan Vu:

Also ich habe in die While-not-terminated-Schleife ein Sleep eingebaut und die Instantiierung des Bitmaps in den Konstruktor des Threads verlagert. Klappt.

Im Konstruktor des Threads bist du ja noch im Hauptthread und noch nicht im Thread-Thread.

[Sir Rufo]

Nur das Sleep verbessert die Situation. Die Bitmap Instanz kann man erzeugen wo man möchte.

Problematisch ist nicht TBitmap an sich, sondern TBitmap.Canvas . Da wird intern etwas Globales verwendet und das fällt einem auf die Füße.

Ein TCanvas.Lock /TCanvas.Unlock sollte eigentlich helfen, aber leider auch nur bedingt. Irgendwann kommt man in einen Deadlock, wenn das zu schnell von unterschiedlichen Threads erfolgt.

Darum bringt die Verwendung von Sleep eine Verbesserung.

Wenn man eine echte Lösung haben möchte, dann sollte man TBitmap im Thread vergessen und dort auf TBitmap32 von Graphics32 setzen.

Zu dieser Erkenntnis kommt man auch hier: How threadsafe is TBitmap

[Bernhard Geyer]

Zitat von Sir Rufo:

Problematisch ist nicht TBitmap an sich, sondern TBitmap.Canvas . Da wird intern etwas Globales verwendet und das fällt einem auf die Füße.

Das dieses Canvas ein Integrales Bestandteil von TBitmap ist sehe ich diese Trennung als Spitzfindigkeit.
Aber was solls mit TBitmap32 oder TPngImage gibts genügend Alternativen.

[Sir Rufo]

Zitat von Bernhard Geyer:

Zitat von Sir Rufo:

Problematisch ist nicht TBitmap an sich, sondern TBitmap.Canvas . Da wird intern etwas Globales verwendet und das fällt einem auf die Füße.

Das dieses Canvas ein Integrales Bestandteil von TBitmap ist sehe ich diese Trennung als Spitzfindigkeit.
Aber was solls mit TBitmap32 oder TPngImage gibts genügend Alternativen.

Nicht wirklich, denn es ist absolut safe z.B. mit TBitmap.Scanline oder TBitmap.Pixels zu arbeiten (was über Scanline geht).

[Dejan Vu]

Zitat von Sir Rufo:

Nur das Sleep verbessert die Situation. Die Bitmap Instanz kann man erzeugen wo man möchte.

Das stimmt nicht. Erst, als die Bitmap im Konstruktor erzeugt wurde, funktionierte es.

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von Sir Rufo:

Nur das Sleep verbessert die Situation. Die Bitmap Instanz kann man erzeugen wo man möchte.

Das stimmt nicht. Erst, als die Bitmap im Konstruktor erzeugt wurde, funktionierte es.

Ich habe es mit DX Seattle ausprobiert und da braucht es nur das Sleep (um augenscheinlich stabil zu laufen).

Da aber Thread und TBitmap nicht so richtig zusammen passen, sollte man das getrost mit einem Sperrvermerk belegen und im Thread auf eine der genannten Alternativen setzen. Ein Sleep in einem Thread ist eher Makulatur und keine stabile Grundlage. Das ist nur legitim um solche Timingprobleme zu lokalisieren.

[Mavarik]

Zitat von Bernhard Geyer:

Zitat von Mavarik:

OK...
Schon funktioniert es!

Zufälligerweise.
Jedes Zeichnen aus dem Thread auf im Hauptprogramm erzeugte Formulare kracht früher oder später.

Deswegen ruft man ja Syncronize auf...