Posted by elect on Oct 19, 2015; 11:27am
URL: https://forum.jogamp.org/Texture-compression-tp4032185p4035512.html

gouessej wrote

There is already a very capable general purpose API to handle textures in JOGL and it's possible to write some SPIs based on third party libraries. It's viable. For example, you can write some code based on Apache Commons Imaging and call your methods in a SPI for JOGL.

I'm harsh but I agree with Sven, we want you to succeed.

I am sorry but it is not at all very capable nowadays. TextureData is basically an old texture2D-oriented class.

Let me bring some observations:

- it does not have depth (only width, height)

- it has an int to represent the internalFormat, an GLPixelAttributes object for the pixel type and the format amd a ColorSpace object. There is no clean way (sometimes just no way) to put all these entities in relationship between each other. You can't go from one to the other. Only internally in the GlPixelAttributes there is a small convertion to retrieve the internalFormat but that's all if I didn't miss anything else.

- it does not have any awareness of layers, faces and swizzle. This reflects on the missing of a method to retrieve the (sub)data of the texture at (layer, face, level).

In gli, I have a format for each API and the independent one.

The GL one holds internal format, external format, type and swizzle.
The neutral one is a very generic one and has block size, an array for the block dimension, number of components, swizzles and flags. This is compression option independent, that is it doesnt matter if the format is compressed or not, it is just a flag.

And gli texture data structure is deeply based on the layers, faces and levels suddivision. I can query any type of memory segment.

This offers a lot of flexibility to support all the different combination, for example loading an cube array with mipmap is as simple as creating three loops.