5 I can actually redesign the ZIP stream based reader to be a bit faster and use
6 maybe less wrapper classes (and potentially less overhead) if I add the
7 ability for the inflate input stream to return a CRC value after some bytes
8 have been read to the output.
12 With `InflaterInputStream` now having access to the CRC, it can now more be
13 used with the stream based ZIP reader code to find the end of entries. I can
14 also see the complete removal of one of the streams and just having an inner
15 stream which is wrapped by the decompressor (which is wrapped by the entry
20 So I could potentially refactor the stream based ZIP reader now that I have a
21 means to test it along with having the size and CRC information from the
26 In fact I can have just a single stream and one object in the outermost class
27 which can handle the stream related details and could potentially be a bit
28 faster. At least when it comes to data which is compressed, the end of the
29 stream will be following when the inflate stream has ended. This means the
30 descriptor can be searched for and checked for validity. On data which is not
31 compressed at all, there will still need to be a manual search. However the
32 benefit here is that since most ZIPs would be compressed (eventually mine
33 will be) is that there is no wasted cycles checking for the end descriptor
34 since it is implicitly at the end of the decompressed data.
38 This also means that the inflater that is part of PNG (which uses ZLib) or
39 really the ZLib part of it can just directly use the inflater stream rather
40 than wrapping it to calculate a checksum.
44 Before I refactor the ZIP stream reader a bit I am going to document some of
45 the history of SquirrelJME.
49 I have much more free time off from work, but I am not really making much
54 Ok, so now I have much cleaner handling of entries with a known size which is