Nothing changed, I just didn't add it because I didn't understand it. Care to elaborate? 😁
Zlib doesn’t track the original size of our file, nor our compression ratio for us. It simply takes the string of our data which we give it and then crunches it down into a compressed form. So lets say we start with a file of 1000 bytes in size. If it’s text, it might compress down to 40 bytes...
When we send that 40 bytes back to zlib to decompress, zlib has do idea of how compressed it is, or how much memory it needs to uncompress it. Unless we tell it the size of memory it needs to reserve, it runs a trial-and-error decompression method for us.
PASS 1; Reserve 100 bytes... Attempt decompress... FAIL, not enough memory to fully decompess.
PASS 2; Reserve 200 bytes... Attempt decomress... FAIL.
PASS N; Reserve 10000 bytes... Attempt decompress... SUCCESS! Return the 1000 bytes of the original, free the temp memory.
That optional parameter lets us bypass that trail and error by telling it the exact size it needs to reserve to return our uncompressed data back to us.
PASS 1: Reserve 1000 bytes of memory. Decompress... SUCCESS... Return 1000 bytes.
(Of course the values aren’t set in 100s of bytes, but instead are much larger by default internally, but it highlights the process.)
For people who are worried about efficiency and minimal memory use, they’re much better served if they use the optional parameter to manually set the return size — especially if dealing with large files which may need multiple attempts at resizing to reserve the right amount of memory for the full decompression.
Use would be similar to:
Text$ = “Whatever we want to compress.... lots more junk”
OriginalSize = LEN(text$)
Compressed$ = _DEFLATE$(text$)
... other program stuff you want to do...
Decompressed$ = _INFLATE$(Compressed$, OriginalSize)
The above tells Zlib the exact amount of memory it needs to reserve the data we send it... Without that optional parameter, it just makes a guess at what’s needed, and then guesses bigger and bigger, until it either succeeds or runs out of memory and finally pops an error.
Inflate without size is for quick and easy coding. Inflate with size is for efficient, quicker programs. If I just wanted a demo for the forums, I probably wouldn’t worry about that parameter (or if I knew my extracted file sizes were small). If I was concerned about FPS, for video ot a game, then I’d store those values and be certain to use them with the command.
EDIT to expand:
And for those curious, I just checked our source to get default size: _INFLATE reserves 10MB by default as a memory buffer to extract to, and increases the buffer by 10MB per pass until it’s large enough to hold your uncompressed data.
