Threads und TBitmaps...schon wieder :-)

[jaenicke]

Locks dienen im Gegenteil eher dem Performancegewinn (oder hier eben anderen Zwecken), weil man damit verhindert, dass jemand "von der Seite reingrätscht". Langsamer wird es meistens eher nicht.

[Benmik]

Ich habe jetzt die Locks eingefügt. Ob es dadurch langsamer geworden ist, weiß ich nicht, aber ich habe dadurch den alten Code wieder durchgesehen und dabei eine völlig neue Erfahrung gemacht: Wenn man eine Bitmap freigibt, dann ist es immer gut, wenn man sie vorher erzeugt hat. Erst ein

Delphi-Quellcode:

Create

, dann ein später eingefügtes bedingtes

Delphi-Quellcode:

Exit

, danach ein unbedingtes

Delphi-Quellcode:

Free

- das ist nicht gut, auch ganz ohne multithreaded. Das

Delphi-Quellcode:

Create

hinter das

Delphi-Quellcode:

Exit

und weg sind die Exceptions. So einfach kann Programmieren sein.

[jaenicke]

Zitat:

Zitat von Benmik (Beitrag 1533284)

Wenn man eine Bitmap freigibt, dann ist es immer gut, wenn man sie vorher erzeugt hat.

Genauer gesagt: Wenn man sie zugewiesen hat, sprich mit nil initialisiert hat.

Solange die Variable entweder auf eine Bitmap verweist oder nil ist, ist es kein Problem ein Free aufzurufen, denn das prüft, ob Self <> nil ist.

Das Problem ist daher nicht das Free oder ein nicht immer aufgerufenes Create, sondern eine fehlende Initialisierung der Variablen.

[himitsu]

Wobei normal der Compiler dann ja auch einen Tipp geben würde, wenn die Variable nicht initialisiert wurde. :stupid: