4 ms·
> The entire input stream must be available (multi-call/streaming mode are not supported) > The entire output buffer must be allocated with a fixed size -- how
by asveikau 6y ago
> The entire input stream must be available (multi-call/streaming mode are not supported)
> The entire output buffer must be allocated with a fixed size -- however, callers are able to query the required size
I have not seen a compression library ask for this before. Chunk-at-a-time is not supported? Whole file in RAM? So no-go for memory constrained environments or large files?
This is from the Windows Internals guy? His reputation is pretty good, maybe I am missing something here.
Edit: The code also keeps the input buffer in a global variable. Weird.
I am going to guess he has a very specific use case in mind for this library, like a bootloader or something, where memory management and multiple files are not as important because you decode once and throw out everything shortly after.
- badsectoracula 6y agoOne use case that came immediately to my mind is virtual texturing (think megatextures like in id Tech 5) or virtual geometry (...which in current hardware can be implemented via virtual texturing). The texture pages can take a TON of disk space so compressing those is important. But you can load (or mmap) the entirety of each page and you know beforehand how big each page will be in memory. (though all that assumes LZMA decompression is fast enough)
- zmodem 6y agoNot supporting streaming decompression simplifies the implementation a lot, which seems to fit well with the project's goals (hwzip does this too: https://www.hanshq.net/zip.html https://www.hanshq.net/zip.html). It should still work with large files on systems where they can be memory mapped.