Address PR MrCrayfishFurnitureMod#608 on watermedia

[SrRapero720]

Address PR MrCrayfish/MrCrayfishFurnitureMod#608 DDS support and catching looks robust enough and can enhance performance on java gif and picture support

[ZenoArrows]

I'm the original author of that PR and I'm interested in implementing the same functionality in WATERMeDIA. The main hurdle is cross-platform compatibility of the texture compressor particularly MacOS support. Originally I used texconv which made it mostly windows-only, so for a new implementation we should probably use something else. Our options are:

Compressor	Open-Source	Mac	Compute	MipMaps
NVTT3	🚫	🚫	⚠ (CUDA)	✅
ISPC TexComp	✅	✅	🚫	🚫
Compressonator	⚠	🚫	✅	✅
DirectXTex / texconv	✅	🚫	⚠ (DX11)	✅

I think out of these four ISPC TexComp is our best option, the only downside is that it doesn't support any GPU acceleration, though its CPU implementation is highly optimized. However a solid CPU implementation is probably more important here, since we can't assume Minecraft players will have a GPU that actually supports compute (or have an Nvidia GPU in the case of NVTT).

One other downside is that ISPC TexComp doesn't support mipmap generation, but Minecraft actually has a pretty decent generator internally that can be leveraged here or we can simply implement it using standard Java image libraries. Thus we can generate the mipmaps in Java before compressing them using ISPC. Not the fastest solution, but again highly cross-compatible.

One remaining issue is BC7/BPTC support on Mac, unfortunately even though Metal supports BC7 Apple does not expose it through their OpenGL 4.1 implementation. Thus we have no other option but to fall back to the inferior BC3/DXT5 compression on Mac (and any other platform without support for GL_ARB_texture_compression_bptc).

Of course there's nothing preventing us from supporting NVTT3 or Compressonator for Windows/Linux and falling back to ISPC for Mac. Or we could forgo texture compression for Mac, since it isn't even supported that well. Though it's important to remember that those two libraries don't perform as well as ISPC when GPU acceleration is unavailable.

[SrRapero720]

Of course there's nothing preventing us from supporting NVTT3 or Compressonator for Windows/Linux and falling back to ISPC for Mac. Or we could forgo texture compression for Mac, since it isn't even supported that well. Though it's important to remember that those two libraries don't perform as well as ISPC when GPU acceleration is unavailable.

Thats what i was considering (before you edited your message xd) anyway, most of the compressing things needs repackage binaries so all the development might be splitted with SrRapero720#watermedia-binaries

and splitted because i want to integrate it into CacheAPI, storing the compressed image in disk to avoid re-compression, but im not sure if that was possible

[ZenoArrows]

and splitted because i want to integrate it into CacheAPI, storing the compressed image in disk to avoid re-compression, but im not sure if that was possible

that was part of the original PR, it stored the compressed/mipmapped results in DDS files on disk which could be loaded quickly afterwards and sent directly to the GPU no decoding or mipmap generation needed.

[ZenoArrows]

Since we're considering implementing two compressors, how about we take a different approach. Since Mac doesn't support BC7 anyway we can use this compressor as a fallback instead: https://github.com/memo33/jsquish

It's a DXT compressor implemented entirely in Java so it will work anywhere and since Mac can't support anything better than that it's good enough as a fallback. So that way we can have a fallback path that's fully implemented in Java and then we only have to deal with native binaries for texture compression on Windows and Linux where we can actually use the much better BC7 compression.

One last thing to decide is how we want to go about integrating the native compressor. For my previous PR I simply packaged the texconv executable with the mod, avoiding the need to use JNI. I would then save the uncompressed image to the disk, silently execute texconv to compress the texture and then load the compressed texture from the disk. The only difference JNI would make is avoiding the need to save the uncompressed image and load the compressed texture from the disk because we can compress it in-memory.