These headers are included quite often and because
<Corrade/Utility/StlForwardString.h> expands to the whole <string>, it
has quite a significant impact.
Other cases like Math/ConfigurationValue.h are not changed at the
moment, as that header is only included together with Utility::Arguments
or Utility::Configuration -- and these classes are still STL-heavy, so
avoiding std::string usage in just the ConfigurationValue
specializations doesn't help anything at the moment.
Similar to what VertexFormat already has -- getting channel count,
channel format, sRGB and color vs depth/stencil properties out of a
PixelFormat value. Very useful for various image conversion plugins.
Similar to PixelFormat, to filter out values that make no sense as a
vertex format (such as sRGB) and add others (such as doubles). And
documenting which are guaranteed to be supported and which not. The
hasVkFormat(Magnum::VertexFormat) and vkFormat(Magnum::VertexFormat)
were also deprecated in favor of the new hasVertexFormat() /
vertexFormat() APIs.
Originally, \def_vk was used for enum values (equivalently to how
\def_gl is used for "enum" values in GL), but I also need to reference
actual defines such as VK_VERSION_MINOR(), so renamed it to \val_vk and
reused \def_vk for actual defines.
GL was missing a check whether given format is available on a target
(for example double types are not on ES), and for Vulkan we need something
similar to pixel format mapping as well.
Similarly to PixelFormat. Will be useful for Vulkan, unfortunately not
so much for GL because there the format is specified by three orthogonal
values and it's a terrible mess.
With API analogous to the (relatively) new AnimationData -- with one
buffer containing all index data and one buffer containing all vertex
data, both meant to be uploaded as-is to the GPU.
This will eventually replace MeshData2D and MeshData3D, backwards
compatibility and wiring up to other APIs will be done in follow-up
commits.
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.
Hugo Amiard