And, exactly as expected, there's many cases that used the (implicit)
ValueInit while NoInit is a better choice. So yeah, minor speedups in
various places such as GL image download.
That's a too harsh behavior, as it'd break user code (instead of just
causing a bunch of warnings) when people update to a commit that
deprecates a new library.
Yes, I plan to merge audio import into Trade::AbstractImporter, but
until that's done, it feels silly to have to pay for the std::string
cruft given that it's present in just two arguments.
The code was splitting on just a whitespace before the changes in
95b3f8578d (2021), so I suppose I just
accidentally copied the same code over from handling the
--disable-extensions and --disable-workarounds arguments, where the user
*is* allowed to use any whitespaces.
And given that just a space worked well for over a decade before,
there's no reason to pessimistically expect the extension strings
suddenly include tabs or newlines.
All that work to reduce header dependencies and yet here it's full of
them, somehow.
Well, given the fallout in various GL tests now I wonder if I should
just chuck the rest along with the state allocation as a PIMPL.
This originated in 7ad928ae42 which looks
like a generic find & replace that removed all early return statements
because the unmasked renderer string on WebGL could expose both the
underlying driver (NVidia, Mesa, ...) and the wrapper (ANGLE, ...).
Ideally the compiler would warn about an unused expression, but
Optional::operator*() isn't const on mutable variables, so it didn't.
Only discovered this because I'm removing the Optional wrapper from this
member, and then the compiler started to warn.
By now I tested on GCC 4.8, various Clang versions, most MSVC versions,
building the library was without warnings on all those, and so I
expected newer GCC to be also silent when it should be. Nope. Ugh.
I wanted to just ignore these, but the RT builds for some reason have
warnings-as-error enabled by default and, UGH, I just want this thing to
finally pass the CI.
Not only the implementation is a template hell full of its own problems,
the internals are also just wrapping trivial bits of STL without adding
anything of value on top, so ultimately any code that actually used this
thing ended up being slower to build, more verbose, harder to reason
about and with thousands of tiny little inefficiencies all over the
place. So let's just finally say no to this idea from 2012.
"These seemed like a good idea at the time." But that was in 2013 and
while that might have been acceptable back then, it's not anymore, it's
all just a complex abstraction that prevents any reasonable resource
reuse and forces a dedicated draw call for each use.
Just do this directly from the corresponding Primitives instead.
Deprecating those allows me to eventually deprecate the (also
overengineered) ResourceManager class, at which point Magnum should be
finally free from the worst design decisions from 15 years ago.
Unfortunately several examples still rely on it (while it only makes
them more complex, not better), have to wait until those are cleaned up
first.
I'm going to deprecate the (awfully inefficient)
DebugTools::ForceRenderer and ObjectRenderer, and need at least
something else to direct the users to. This should suffice.
The NoInit constructor no longer results in an Array with a custom
deleter which would prevent the resulting MeshData from being used in
plugins, and all contents are subsequently overwritten, so there's no
reason to not use it.
This was done back in October 2024 for all plugins in the magnum-plugins
repository, here it was blocked by usage in (now deprecated) MagnumFont.
In comparison the AnyImageImporter etc. plugins *are* meant to be
constructed directly by plugins that depend on them, so for those
nothing changes.
With StbTrueTypeFont no longer being embarrassingly slow due to a stupid
error, the MagnumFont plugin doesn't really provide any advantage
anymore. Originally I thought I'd update it to not be forcibly relying
on a TGA format and maybe add kerning support, but the image + text
format is extremely inefficient compared to basically anything else and
so I don't see a point in supporting it further. Marking it as
deprecated should also hint to people that using this thing is not a
good idea.
The MagnumFontConverter plugin was also the only user of the
AbstractFontConverter APIs, which right now are the last that didn't go
through a STL cleanup process. I plan to make a converter plugin for
font "minification" using HarfBuzz subsetting functionality, and not
having to support anything else that relies on the outdated APIs will
make the font converter API updates a bit easier.
Finally, the MagnumFont plugin was also the last one that directly
instantiated the TgaImporter plugin, instead of going through
AnyImageConverter. Marking it deprecated allows me to deprecate direct
instatiation in the remaining plugins as well.
The previous set of commits is from 2022 and I had them stashed in a
branch because I was trying to use those as an opportunity to tune SIMD
String APIs. Unfortunately, shortly after, other things got a priority
and I never got back to these.
The previous code was exception-ridden horrible junior implementation
dating back to early 2010s, so even if the code from 2022 might not be
giving the best possible performance, it's still a vast improvement, so
there's no reason to not use it.
Because MeshTools::removeDuplicates() uses a STL hashmap, it's quite
bad. So bad that on the Rungholt scene it takes 4 seconds out of 7.3 for
the whole import process.
Now I'm able to measure -- with the Rungholt scene from McGuire
archives, it takes it a whooping 7.3 seconds, measured with
magnum-sceneconverter --info-meshes --profile rungholt.obj
Compared to that, AssimpImporter in the default configuration takes 10.3
seconds, but with
magnum-sceneconverter --info-meshes --profile -I AssimpImporter \
-i postprocess/JoinIdenticalVertices=false,postprocess/SortByPType=false \
rungholt.obj
it takes just 4.3 seconds. And has the same vertex data size in total,
so that should probably be the default. I got some work to do, then.
Vladimír Vondruš