Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Same as the corresponding Corrade change. Should make
MAGNUM_BUILD_STATIC_UNIQUE_GLOBALS working also in cases where Magnum is
linked to just DLLs but not the main application executable. Such as
various plugins or native Python modules.
It isn't a nice UX to force users to hardcode a DLL name of their own
application when building a *dependency library*, but is a simple enough
middle ground between global symbol deduplication not working at all and
having to loop through all possible DLLs with EnumProcessModules() until
a symbol is found.
This is now the preferrable way to set options to plugins that get
delegated to from other plugins, instead of
Until now there wasn't a general command line interface to pass options
to plugins that get delegated to from other plugins, such as image
converters used by scene converters. Due to that limitation, e.g.
GltfSceneConverter had to add an [imageConverter] configuration group
that it then copied over to the chosen image converter. But such
approach obviously doesn't scale -- every converter would have to do the
same, would have to repeat the whole testing process, and basically the
same would need to be done for all importers delegating to image
plugins. Nightmare.
So there's now --set, which allows arbitrary options to be set for
arbitrary plugins, and that's the preferrable way now. To avoid having
to maintain two ways to do the same, the [imageConverter] group will get
removed eventually.
This was an annoyance with GltfImporter's customSceneFieldTypes, where
it just wasn't possible to set the options through AnySceneImporter or
magnum-sceneconverter -i argument without causing a warning to be
printed.
The behavior is now that if a plugin configuration subgroup (but not the
root group) is empty, it's assumed that new values are meant to be added
to it, and thus it doesn't warn on them.
With the intention that those will eventually contain also things like
YUp / YDown, PremultipliedAlpha and such.
This commit is mostly just busywork, wiring this into [Compressed]Image,
[Compressed]ImageView and Trade::ImageData and ensuring the flags get
correctly propagated during moves and conversions. Unfortunately in case
of Trade::ImageData it meant deprecating the current set of constructor
in order to insert an ImageFlags parameter before the importer state
pointer.
The only non-trivial piece of logic is when a 2D
[Compressed]ImageView gets converted to a 3D one, then the Array bit is
implicitly dropped, as 2D arrays of 1D images are not really a thing.
Instead, it's now possible to add new flags when doing the conversion --
for example to turn a 2D image to a (single-layer) 2D array image.
Minor but very important convenience feature, especially useful when
dealing with command-line apps. This now works:
magnum-imageconverter a.png a.jpg -c jpegQuality=0.75
The AnyImageConverter gets the jpegQuality option and then
automatically propagates it to the concrete plugin (which is either
JpegImageConverter or StbImageConverter), possibly warning in case the
target plugin doesn't recognize given option (i.e., doesn't list it in
its default configuration). Previously the user had to always specify a
concrete converter implementation using -C, which was rather annoying
and nonintuitive.
The 32-bit float depth be needed for the upcoming OpenEXR plugin, added
also the remaining ones that will be eventually supported by KTX and DDS
plugins.
This deliberately doesn't follow the PixelFormat enum naming, as RGBA
components make no sense for most vertex data. Checking Metal and
WebGPU, they seem to have arrived at a similar conclusion, only VkFormat
is an outlier.
Instead of prefixing every value with (Compressed)PixelFormat::,
printing that just once. Also moved the name table to an external header
so it can be used later for configuration value parsing. Compared to
the previous commit, Bloaty reports a save, meaning these two commits in
total save about 4 kB:
VM SIZE FILE SIZE
-------------- --------------
+687% +3.70Ki .rela.dyn +3.70Ki +687%
+15e2% +1.26Ki .data.rel.ro +1.26Ki +15e2%
[ = ] 0 .strtab +100 +0.1%
[ = ] 0 .symtab +48 +0.2%
-50.0% -8 [LOAD [RW]] -8 -50.0%
-3.1% -888 .eh_frame -888 -3.1%
-1.5% -1.92Ki .text -1.92Ki -1.5%
[ = ] 0 [Unmapped] -1.97Ki -32.2%
-38.5% -4.19Ki .rodata -4.19Ki -38.5%
-0.7% -2.02Ki TOTAL -3.85Ki -1.0%
Well. Bloaty reports a 0.3% increase in Debug and 0.1% in Release, but I
guess if the enums would be larger, the savings would be actually
significant.
GL has an extension, but only for ES, not on desktop. Vulkan has
nothing yet (due to there being just ARM that implements it, no other
vendor), except those being listed in a KTX format specification.
Minimal updates (just the include guards) so Git is hopefully able to
detect the rename and track the history properly.
Everything except Magnum::GL doesn't compile now.
Too much burden to implement. Nope. Sorry. All APIs were just asserting
that it's not enabled at the moment, so I may as well just remove it
completely.
Vladimír Vondruš