New PNG inputs for benchmarking non-compressed, non-filtered data.

[anforowicz]

PTAL?

The new test images are somewhat artificial, but they help to see the performance of the bulk of the PNG decoding code. Runtime overhead of this code is relatively small when compared to the overhead of decompression (mostly in the fdeflate crate) and unfiltering (in src/filter.rs), but performance of this code is still important (e.g. as discussed in another discussion thread, optimizing this code can yield 10+% of gains for a more realistic test corpus). And I think that these new test images will be a useful tool for evaluating performance of this code (which may be more difficult to confidently measure using other test inputs).

I am adding 2 separate images, because I think that:

• The 128x128 image will be useful for evaluating performance of copying the image data out of a PNG file
• The 8x8 image will be useful for evaluating constant costs (e.g. when trying to optimize handling of small images - favicons, emojis, etc.)

[fintelia]

I wonder if it would be better to add a new benchmark that constructed these uncompressed files on the fly. That would enable us to have a larger number of variations without having to check in all the (uncompressed!) files into git.

In particular, it might be interesting to try breaking up the files into different sized iDAT chunks (8KB vs 64KB vs unlimited), and to try some much larger files (some decoders have a performance cliff when the image no longer fits in the L2 cache).

[anforowicz]

I wonder if it would be better to add a new benchmark that constructed these uncompressed files on the fly. That would enable us to have a larger number of variations without having to check in all the (uncompressed!) files into git.

Sounds good. I don't have a strong reason to work with actual files (rather than generating inputs at test runtime), but let me list some weak reasons below:

• Consistency with the existing benchmarks
• Being able to use the PNGs in other benchmarks (e.g. in benchmarks that also cover C++/Rust FFI, or in benchmarks of other decoders like libpng or wuffs)

[anforowicz]

@fintelia - what are the next steps for this PR? Are there any actions I should take from my side? (once this gets merged, I plan to rebase and submit the next follow-up I have lined up here: master...anforowicz:image-png:idat-straight-to-zlibstream)