Improvements for the Java/JNI bindings about ktx-software HOT 4 OPEN

Thank you for starting this discussion and most especially for your willingness to improve the JNI.

Re. NamedFile stuff, the native functions accept UTF-8 file names which just work on macOS and Linux. On Windows the functions convert to the proper wide-chars before attempting file open so they work there too. Given this is should be possible for the JNI functions to work. If JNI filenames are 16-bit then a conversion to UTF-8 will be needed.

Re @exception in the documentation, it is used because that is the only way I found document the errors in Doxygen. Since this is a C API there are clearly no real exceptions happening. If JavaI supports exceptions, though the wrapper should probably check all return codes that throw if it is not KTX_SUCCESS.

There are functions in libktx for converting VkFormats to human readable strings and vice-versa. (Not sure if the latter is in libktx or just in some of the commands.)

from ktx-software.

Trying to pull together a few "TODOs" from related issues and this one.

(EDIT: A summary of the tasks is now in #886 )

In recent comments here and here, you mentioned

I agree CreateFromMemory should be exposed.

The JNI binding should absolutely expose ktxTexture2_GLUpload and, if there is a Java Vulkan wrapper, ktxTexture2_VkUpload.

I'll start with CreateFromMemory,because it is crucial and less controversial.
For the other functions, @ShukantPal voiced some concerns, so I'd probably defer that until we have a clear idea whether this will work exactly as intended.

In another recent comment, you mentioned

You can transcode the swizzled t to KTX_TTF_RGBA32

In that context, I noticed that the KTX_TTF_RGBA32 constant is not yet defined in the Java KtxTranscodeFormat class. I'll add this, as part of the ~"general cleanup" (and look for other missing constants there as well...)

Somewhat related: The current documentation at https://github.khronos.org/KTX-Software/libktx/group__reader.html#ga90cc33928a2dae962fb94b3fa2f6575d says

The following transcodeFlags are available.

That's it. It doesn't say what they are.
This might be caused by some renaming, related to ktx_texture_decode_flags and ktx_transcode_flag_bits, related to

In https://github.com/KhronosGroup/KTX-Software/pull/879/files/a512cc5373931777c9bf3f4d831148f770dd784a#r1537201514 you mentioned that a part of the documentation should be updated, even on the native side. This will probably affect the documentation of the JS/Python/Java bindings, so I'll have to review that carefully.

In #879 (comment) , you mentioned that one of the new tests could also compare the image data. And I agree that the tests should be more thorough (and many of the existing tests could be improved in this regard). But it's sometimes hard to know what can reasonably be tested, and how exactly the required data can be obtained. The improvements here will therefore (have) to be iterative.

In the same comment ( #879 (comment) ) you mentioned

To make my suggestion work you will have to call t.writeToMemory then CreateFromMemory but didn't you tell me those functions aren't exposed in JNI. They need to be.

I'll have to look at the details of the 'inflate...' functions. I already started implementing the createFromMemory function locally (and will have to see into which PR this should go. This is more than a "trivial bugfix", or "routing throgh a function". This already does raise a bunch of questions that I'll try to summarize a bit later).

The writeToMemory function already does exist, in the KtxTexture class, carrying the comment

    /**
     * This **might** not work (INVALID_OPERATION for some reason)
     */

Yeah. I'm not sure what to do with that. I'll consider it broadly as "one of these things that should be part of an overall improvement"....

There are functions in libktx for converting VkFormats to human readable strings and vice-versa.

Regardless of where this is offered in the native part: It would very likely make sense to offer that translation directly on the Java side. Having a switch (c) { case 123: return "FOO"; } is orders of magnitude simpler and easier to maintain than trying to call some native function there.

Some tasks - preliminary:

(EDIT: These have been moved to #886 to better keep track of them in the context of a PR)

from ktx-software.

For the other functions (GLUpload and VkUpload)

At the native level there is only one VulkanSDK which reduces the issues considerably compared to OpenGL. In #877 you mentioned "mix(ing) different JNI libraries that only communicated via some GLuint someOpenGLObject". I think that is the major issue. If that works then the upload functions should be usable in Java. For GL #708 will likely need to be fixed. The fix involves adding a function to set the address of the GetProcAddress function to use.

This might not work (INVALID_OPERATION for some reason)

Need @ShukantPal's help re. this.

There are functions in libktx for converting VkFormats to human readable strings and vice-versa.

Regardless of where this is offered in the native part: It would very likely make sense to offer that translation directly on the Java side.

Any such file should be generated as we do with ktxVkFormat.java to avoid headaches keeping it up-to-date over the long term.

Thanks for the task list.

from ktx-software.

Any such file should be generated as we do with ktxVkFormat.java to avoid headaches keeping it up-to-date over the long term.

I fully agree for the VkFormats. There are many of them. But this referred to other classes that emulate 'enums'/flags via public static final int variables. Sure, the question about updating them applies there as well (and the missing KtxTranscodeFormat.KTX_TTF_RGBA32 is one example). But except for the VkFormats class, none of these classes is currently auto-generated. So unless we completely refactor the code and build process, creating these functions manually should be a reasonable start.

from ktx-software.