Compressor Quality - Fast, Normal, Best

Regarding iOS 2D Texture Overrides, documentation says, "Choose Fast for quickest performance, Best for the best image quality and Normal for a balance between the two."

Is "quickest performance" at runtime or just during development/compiling? In other words, if I'm willing to wait a little longer, do I want to select Best? Does the quality of the compression have any bearing on how long a game will take to load or start or anything?

 

For most texture import settings there's a "Compression" setting with a "Low Quality, Normal Quality, High Quality" setting. These generally have runtime performance implications as they'll use smaller vs larger texture formats.

For iOS (and some Android formats) you get a "Compression quality" setting which is purely build time. The compressed texture asset generated and used by the game is the exact same file size and performance regardless of which option you choose. This will have no bearing on load times for the user. But a single large (say 4096x4096) texture set to best quality could take several minutes to an hour to compress (depending on your computer). The build time for a project with a lot of textures can be significant if setting them all to Best. Generally leave them to normal, and only set textures to best when absolutely necessary. You may want to set a texture to low temporarily if you're modifying it frequently.

Once Unity has done a build they should be cached and the textures shouldn't need to be compressed again if they haven't changed. However note that changing the Build Settings Platform will potentially cause it to clear that cache and re-compress!

 

Thanks, @bgolus ! Okay, so the better the compressor, the better-looking the image might appear, but at the cost of more time when you click the Apply button.

 

Not just that, but it'll cost more at runtime.

 

No, it won't.

Compression quality can be a factor at runtime add it changes the compression format. Different formats may have different compression ratios, and thus different file sizes / memory usage. The more the memory usage, the slower the texture read at runtime.

Compressor Quality doesn't change the format, only how long the compressor spends trying to find the best match to the original art, or various other heuristics it might use to determine the "best" quality. All GPU hardware supported texture formats have one thing in common, which is they have a constant memory usage for each block of pixels regardless of the contents. Different textures have different block sizes and memory usage per block.

An uncompressed RGBA texture is 32 bits per pixel, so a 4x4 texture is 512 bits or 64 bytes. This is a 1:1 ratio as the ratio is in comparison to that uncompressed format. A DXT5 texture is an RGBA texture with a 4:1 compression ratio, so that same 4x4 texture will only be 128 bits, or 16 bytes. A PVRTC 2 bpp has a 16:1 compression ratio so that 4x4 texture would be only be 32 bits, or just 4 bytes ... though PVRTC has a min block size of 8x8 so it would actually be 16 bytes still...

Different compression formats work in different ways, and there's no one way to compress. All GPU formats are also lossy so a decision about what data to lose has to be made. Some compressors try several different combinations of data loss and compares with the original to try to find the "best" option. It might try hundreds or thousands of combinations and still not find a "best" one, so usually you're setting a time or iteration limit. That's what the Compressor Quality is changing between, different presets with max iterations or time limits.

 

Thanks again, @bgolus .

 

非常感谢你的分享，我以前误会了！@bgolus

 

Out of curiosity, how much a difference do you personally notice between the Fast and Normal quality options? I'm using ASTC 4x4 and Fast during development, because my old 2015 Macbook Pro takes forever to compress the 8k atlases I'm using at Normal quality. Though when I try to recompress at Normal quality before an important build, the quality doesn't seem too different to me. I'm still going to recompress at Normal quality in case people with sharper eyes can appreciate the difference in quality, but I was hoping to hear some anecdotes from other devs.

 

I really want to know, it possible to set this Compressor Quality by code?