101arrowz / fflate

High performance (de)compression in an 8kB package

Home Page:https://101arrowz.github.io/fflate

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

return uncompressed size instead of resized output buffer

sigurdle opened this issue · comments

I see that when you pass an outputbuffer that is too large, then the decompression calls slice on that output buffer to return a buffer that is the correct decompressed length.

It would be nice to be able to pass an output buffer that is too large, but have the decompression routine return the length of the decompressed data instead of calling slice on the buffer.

This is useful if you want to decompress many compressed buffers, and re-use one output buffer that is large enough for all of them. In my specific case its for decompressing a tiled image, each tile is zlib compressed and they're all the same size, except the "edge" tiles.

The output buffer option is provided specifically so that the function does not reallocate at all, so this is probably a bug. I'll verify that I can reproduce and fix it in the next release.

I just double checked by passing in my own buffer that is 1 byte more than the uncompressed size, and it results in a new Uint8Array

Last line in "inflt"
return bt == buf.length ? buf : slc(buf, 0, bt);

// typed array slice - allows garbage collector to free original reference,
// while being more compatible than .slice
var slc = function (v, s, e) {
    if (s == null || s < 0)
        s = 0;
    if (e == null || e > v.length)
        e = v.length;
    // can't use .constructor in case user-supplied
    var n = new u8(e - s);
    n.set(v.subarray(s, e));
    return n;
};

Those two last lines I think would be more efficient with
var n = new u8(v.subarray(s, e)); // no 0-initialization necessary

last line in inflt could maybe be:

return bt == buf.length ? buf:
(!noBuf)? buf.subarray(0,bt):  slc(buf, 0, bt);

or something like that

That is exactly the approach I had in mind. Will release in v0.8.1.

Released in v0.8.1.