calculate serialized size and actually serialize in two separate calls

[AnonN10]

Is there a way to calculate the size of the buffer you'll be serializing to (so that you allocate the memory and not the ktxTexture2_WriteToMemory function) and then write the texture data to it?

[MarkCallow]

There is no function for that but it would not be difficult to write one for libktx. There are a couple of wrinkles preventing it being easy outside the library. There isn't any way to get the supercompressionGlobalData byte length from a ktxTexture2 object (only needed for textures compressed with BasisLZ/ETC1S). The internal hashlist has to be traversed to calculated the length of the key-value data.

I'd happily accept a PR to add such a function to libktx.

An alternative is to add a variant of ktxTexture2_WriteToMemory that lets you provide a pointer to a memory allocator.

Which is better for your situation?

[MarkCallow]

A variant of ktxTexture2_WriteToMemory that behaves like some of Vulkan functions where you first pass nullptr as a buffer to get size of the data

That sounds good. I'm not going to have time for something like this for at least a month so probably best if you attempt to do it. The simplest way is probably to start by modifying lib/memstream.c to allow creation of a memstream with a nullptr and in the write function of such a stream to increment the internal position as usual but to not to copy data. The read function for such a stream should return KTX_INVALID_OPERATION.

[AnonN10]

Should both ktxTexture1 and ktxTexture2 have identical set of functions in their virtual table?

[MarkCallow]

Should both ktxTexture1 and ktxTexture2 have identical set of functions in their virtual table?

Is this a general question or specific to this topic? In general the answer is yes. Re. this topic I don't see any need to add a new function, only to modify the existing ktxTexture?_WriteToMemory functions to support a null buffer pointer.

[AnonN10]

I don't see any need to add a new function

If the new way is to first call with nullptr and then with pointer to the data, then how to preserve backwards compatibility if we no longer have the way to leave the memory management to the function? We need a separate function.

[MarkCallow]

Oh! Of course.