GetMem Problem

[blablab]

GetLastError ist immer 0
(Wie vorher geschrieben hat deshalb die Fehlereingrenzung so lange gedauert)

"and not 31"
Das ist aus der function BytesPerScanline aus der unit Graphics geklaut.
Das "... + 31) and not 31" bewirkt, dass das Ergebnis immer ein Vielfaches von 32 ist. Zum Schluss wird es dann mit div 8 von Bit in Byte umgerechnet. Das bedeutet die benötigten Bytes einer Scanline werden immer zur nächsten 4Byte-Grenze aufgerundet. Das hab aber nicht ich so bestimmt, sondern Windows. Ich halt mich nur dran

Aber der Witz an der Sache ist ja, dass es immer einmal funktioniert und einmal nicht.
Es funktioniert immer bei dem Buffer, dessen Speicher zuerst reserviert wird. Ich kann GetDIBits tausend mal aufrufen mit hundert verschiedenen Puffern und es funktioniert immer genau bei dem Buffer, dessen Speicher zuerst reserviert wurde und bei allen anderen nicht. Die restlichen Parameter sind identisch. Und wenn die Parameter einmal funktionieren, dann müssten sie doch beim zweiten mal immer noch funktionieren...
(Windows könnte zwar meine übergebene Variable ssBmpInfo verändern, wenn ich aber immer nur eine Kopie von ssBmpInfo übergebe ändert sich auch nichts.)

[blablab]

OK, ich habs jetzt verstanden.

Man sollte tatsächlich nie GetMem zusammen mit GetDIBits verwenden. Es geht nur mit VirtualAlloc, da sich die Daten in einem physikalisch zusammenhängenden Speicherblock befinden müssen, was bei GetMem nicht unbedingt gegeben ist. Das ist scheinbar eine undokumentierte Bedingung von GetDIBits.

Danke Microsoft für die vielen Stunden Rätselspaß...

[Medium]

Ich finde das es recht nachvollziehbar ist, dass ein Bitmap ein Stück Speicher ohne Löcher braucht. Wertvoller fand ich jetzt die Info, dass GetMem fragmentierte Bereiche liefern kann! D.h. GetMem gibt aus Prozesssicht schon zusammenhängende Adressen, aber physikalisch können die wild verteilt sein, auch wenn es als ein Block reserviert wurde - verstehe ich das richtig?

[blablab]

Scheinbar ist das so und zwar nicht nur bei Delphis GetMem sondern bei so ziemlich allen Standard-Speicher-Allozier-Funktionen jeglicher Programmiersprachen.
Das Problem ist auch, dass der Speicher für GetDIBits mit einem Aufruf von VirtualAlloc reserviert werden muss und GetMem benutzt scheinbar mehrere Aufrufe. (Ob es VirtualAlloc ist weiß ich nicht.)

Das ein Bitmap ein unfragmentiertes Stück Speicher braucht mag sinnvoll sein. Aber wenn man solch ein unfragmentiertes Stück Speicher mit keiner Standard-Speicher-Allozier-Funktion jeglicher Programmiersprachen bekommt, dann wäre das doch wenigstens ein Mini-Kommentar in der Dokumentation wert, oder?