[Zlib-devel] stored-block size limit?

[Greg Roelofs]

>> It's not clear to me if there's some technical (tuning) reason for this
>> connection or if it's simply a matter of using the buffer sizes that
>> happen to be available.  There's no particular reason why you *couldn't*
>> emit a 64K stored block at one of the lower memLevels, is there?

> Sure you could emit it, but you might not know if you should.  The trick 
> is that in order to know that the 64K of data could not be compressed to 
> less than 64K, so you need to be able to compress 64K.  If you don't 
> have enough buffer space to compress 64K, then you can't do that.  Small 
> memLevels limit how many literals can be accumulated, hence limit the 
> size of a stored block.

That's about what I imagined.  But if you were willing to do a two-pass
scheme, presumably you could aggregate smaller stored blocks into bigger
ones on the second pass.  That's gross and nearly pointless, of course,
but it's the principle of the thing...

> p.s.  Greg's comment on the zlib technical details page is apparently 
> correct.  I do like to calculate stuff like this.

:-)

Btw, if you want another little brain-teaser, can you explain why the
results of the Z_HUFFMAN_ONLY strategy are (empirically) completely
independent of the compression level?  When I looked at the code, it
seemed like levels 1-3 might produce a different result from levels 4
and up, but this is never seen.  Is it possible?  (I just ran one of
the more exhaustive tests on this--5^8 PNG filter combos for each
compression level, and every single one was 9-way degenerate.)

Greg