This makes it much less annoying to pass arbitrarily typed data, such as
std::uint8_t or char8_t and what not. It was already done like this for
the new shader converter plugins, where the input is often 32-bit ints
for SPIR-V.
OTOH the internal virtual API is kept with ArrayView<const char>, as
that makes it easier to operate on by the implementations.
This allows to better describe memory ownership and transfer it instead
of forcing the plugins to allocate their own local copy if the import
happens in-place on the imported data. Right now that's mainly for the
openFile() use case, which implicitly allocated an Array with file
contents only to pass it to openData() which then made a copy because it
could not make any assumption about data scope.
In other words, certain plugins (TgaImporter, KtxImporter, DdsImporter,
CgltfImporter and possibly others) will now have their peak memory usage
*halved*.
Hah, so many overloads. Not providing mutable access to keys or layer
offsets as that would break the invariant of the internal array always
being sorted.
Those have 3 pointers at least, my limit for passing by value is trivial
copyability and two pointers. I hope that reflects the actual HW at
least vaguely, heh.
And add a comment explaining why we don't check the pointer for empty
meshes -- otherwise empty interleaved meshes would fail with stuff like
Trade::MeshData: attribute 0 [0xc:0xc] is not contained in passed
vertexData array [0x0:0x0]
which ... helps nobody.
Because otherwise we don't properly test all cases. Case in point --
attributeData(UnsignedInt) wasn't correctly propagating the array size,
causing the new tests to fail. Fix in the next commit.
Long ago, during one of the few initial MeshData iterations. there was
no VertexFormat, but rather Trade::MeshAttributeType. I managed to get
rid of it mostly, except this place.
Originally I wanted to show how to convert a JPEG to an EXR directly,
however after trying and miserably failing to implement that inside
OpenExrImageConverter I realized the plugin is definitely not the place
where to perform such conversion. So this will have to wait until
there's some proper API in TextureTools or somewhere.
In case of --layers and --levels this only works if the input images
have a single level, otherwise --level has to be set. The internal
implementation would be too complex otherwise. As a consequence,
combining a set of 2D mipmapped images into a 3D mipmapped image means
one first has to combine particular 2D image levels to 3D levels and
then combine all 3D levels to a 3D mipmapped image, it can't be done in
a single step and it also can't be done by first combining levels and
then layers.
The multi-level APIs still don't check anything regarding level sizes
and order since for example *.ico has no restrictions at all. But the
rest (like non-zero size) is a restriction for all file formats I'm
aware of.
TgaImageConverter test had to be adapted, I expect a lot of breakages in
plugins tests as well. But user code should be fine I think. Also
reduced the rather excessive dimensions in AbstractImageConverterTest,
since the allocation requirement now made the default Emscripten heap
OOM.
To avoid combinatorial explosion of functions that have to be
implemented on the plugin side, the single-image variants proxy to the
multi-level variants, if available.
THe plugin interface string had to be bumped because otherwise there was
a *really nasty* silent ABI break where instead of doSetFlags() it was
suddenly calling doConvert().