You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far I've assumed that PNGs rarely use static huffman blocks because the symbol distribution is very different from other sorts of compressed data. As a result, there has been very little effort to make handling of static blocks fast. The most significant overhead is that table building is repeated every time a static block is encountered.
At a minimum, table building should be skipped for empty static huffman blocks (which don't make a ton of sense in a PNG, but are produced by certain kinds of zlib flush operations). Further improvements could be made by reusing decoding tables between consecutive static huffman blocks or even building the tables once and then caching them in a static variable.
The text was updated successfully, but these errors were encountered:
So far I've assumed that PNGs rarely use static huffman blocks because the symbol distribution is very different from other sorts of compressed data. As a result, there has been very little effort to make handling of static blocks fast. The most significant overhead is that table building is repeated every time a static block is encountered.
At a minimum, table building should be skipped for empty static huffman blocks (which don't make a ton of sense in a PNG, but are produced by certain kinds of zlib flush operations). Further improvements could be made by reusing decoding tables between consecutive static huffman blocks or even building the tables once and then caching them in a static variable.
The text was updated successfully, but these errors were encountered: