Compress/decompress progress callback about astc-encoder

[solidpixel]

I don't see many scenarios where this is really necessary. How slow is compression on your system?

For typical compression settings and image sizes, compression is normally only 1-2 seconds per image. Decompression is two orders of magnitude faster than that.

For a typical asset compression workflow (many textures, many mipmap levels) a progress bar is more usefully done based on the completion of the overall texture pool, rather than single images.

[dhalsimax]

Oh yes you maybe right. Anyway not many have lots of cores and ghz, For example I have embedded the library in a tool that compress, for only a 2D game, hundreds of 1024x768 textures and in exaustive quality 8x8 block taking almost 160 seconds per texture on an older i7-7700HQ dell's notebook using multithreading. I also have dozen of 8k textures taking much much more. Think that also moving resolution of such 2D games in the near future above in full hd would exponentially add seconds for hi res textures.

[solidpixel]

True, -exhaustive compression can be very slow. IMO the image quality benefit for real game usage probably doesn't justify the improvement over -thorough.

[dhalsimax]

You maybe right too don't mind. I'm osbessed by verbosity since I've switched from the incomprehensible window's background hd crunching to the well verbose linux some decades above. From a conspiracy perspective, I believe that Microsoft has been pressuring manufacturers for years to no longer include the hard disk activity LED in their computers. So jokes aside, feel free to close this request I will buy a faster notebook soon. It was a pleasure, regards.

[solidpixel]

Leave this open - will take a look at adding it, as it's not a lot of work to do so.

[solidpixel]

Try this PR: #451

I only added callback support for compression - decompression really doesn't need it.

[solidpixel]

Merged.

[dhalsimax]

Nice. Thanks.