Png load time test3/28/2024 ![]() if you'd like better-than-zlib ratio, with comparable load-times go for LZHAM deterministic parsing variant.the same goes for dash, but (sorry to say) it's source code looks like PoC (and seems OOB/overflows are possible), so I'd probably NOT use it in real world software.so for example it compressed 18Mb to 9.1Mb (when zlib shrinked it to 5.5), but the loading is almost 3 times that of zlib.if you don't care about file size, but do care about load time, go for snappy.Now what (I think) these results tells us? So skipping the PNG part this is actually comparison of few compression/decompression algorithms. Snappy, data-shrinker, bsc were compiled with -O2, lzham with -O3 (accidentally), I'm not sure if lz4 had O2 or Os, I hope the first.Īlgorithms were allowed to use only one thread (I think bsc is able to use more). I've added few known, and lesser known algorithms Please, keep in mind, this is PoC-like code, so it's more hacky-do-the-job-way than elegant way. Source code of test app is available in the repo. So I've created small app suitable for doing the test. The only thing you actually need to do is to write your own lodepng_custom_inflate and/or lodepng_custom_deflate. I've actually decided to do the second thing. It allows exchanging both whole ZLIB or only inflate/deflate methods. So I've taken a look at it, and it's seems it's once of those pieces made by developer for developers. I think I've header about LodePNG some time ago, but must've forgotten about it. ![]() Some time ago, Noel Llopis tweeted about lodepng (actually, I've seen RT via Glenn Fiedler). I've even tried it once (at the beginning of 2011), but I was trying to do that using libpng, which was somewhat painful. Main idea was to change ZLIB's compression/decompression used in PNGs to different algorithms and see what's gonna happen. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |