Near-infinite compression time on some textures.

[jitspoe]

The Godot engine is using this, and there's some code in EtcBlock4x4Encoding_RGB8.cpp and EtcBlock4x4Encoding_RGB8A1.cpp that has multiple loops with very large values.

iMaxRed2 = 252645152, iMaxGreen2 = 252645152, iMaxBlue2 = 252645152

            for (int iRed2 = iMinRed2; iRed2 <= iMaxRed2; iRed2++)
            {
                for (int iGreen2 = iMinGreen2; iGreen2 <= iMaxGreen2; iGreen2++)
                {
                    for (int iBlue2 = iMinBlue2; iBlue2 <= iMaxBlue2; iBlue2++)
                    {

After several minutes iRed2 was only at 15/252645152. I've attached the file I was trying to import:

Importing just the red and green channels is fine, but importing all of them results in a near-infinite loop.

This code looks suspect, but I'm not sure if that's by design or not:

		int iMaxRed2 = iColor2Red + (int)a_uiRadius;
		if (iMaxRed2 > 15)
		{
			iMinRed2 = 15;
		}

Several if statements check the max value, then set the min value. Should they be setting the max value to 15 instead?

[richgel999]

I'm not on this project - it's dead. This appears to be bugs/typos to me.

[Calinou]

For future readers, using a library like https://github.com/wolfpld/etcpak should provide faster compression. See this benchmark: https://aras-p.info/blog/2020/12/08/Texture-Compression-in-2020/

Note that Godot's master branch has switched to etcpak, so this should no longer be an issue in Godot 4.0 and later. This wasn't backported to the 3.x branch as support for GLES2-only formats is needed there.