Der "Fehler" ist eigentlich das alle
GDI-Ressourcen eine Thread-Affinität anhaftet. Sie dürfen eigentlich nur im erzeugten Thread verwendet werden. Die fehlende
VCL-Threadsicherheit ist der
GDI-Thread-Affinität geschultet. Ein einelne Anpassung hier löst nicht das grundsätzliche Problem.
Ich habe nicht behauptet, eine allgemeingültige Lösung für alle Probleme der
VCL gefunden zu haben.
Wie vieles ander in der
VCL auch nicht. Deshalb: Alles was mit
VCL/
GUI zu tun hat immer im Hauptthread erledigen oder dafür sorgen das die Ressourcen im entsprechenden Thread erzeugt werden. Wobei hier globale instanzen wie TApplcation/TScreen hier einen trotzdem einen Strich durch die Implementierung machen können.
TCanvas hat einen integrierten Locking-Mechanismus, sodass man durchaus mit allen (vernünftig implementierten) TGraphic-Nachkömmlingen parallel in mehreren Threads arbeiten kann. Das praktiziere ich mit TPngImage, TBitmap und TJvGIFImage erfolgreich ohne irgendwelche Probleme. Nur das TJPEGImage hat zicken gemacht, weil der Lock nicht angewendet wurde und genau das musste nachgeholt werden.
Wer soetwas über Synchronize erledigt, hat wohl den Sinn der Threads nicht begriffen.
Du meinst eher: Bis Windows dem Prozess den "
GUI-Ressourcen-Hahn zugedeht hat". Den "normaler" Speicher hätte der Prozess wohl noch GB-Weise anfordern könnnen.
Du hast recht, aber man kann auch jedes Wort auf die Goldwaage legen und es läuft dennoch auf dasselbe hinaus: Der Prozess wird angehalten und gekillt, weil irgendwelche Limits des BS erreicht wurden.