The reason it wasn't done is likely just neglect, that the code wasn't
updated since it was made originally, before I knew what noexcept is
useful for.
Is critically needed for the GltfImporter now, as the per-data importer
state is not useful on its own anymore and needs the Utility::Json
instance as well. And doing the same for AnyImageImporter as well for
feature parity.
Well, guess why I was postponing this for so long, because there are way
too many combinations, then there's too many ways each variant can go
wrong, one has to document and test everything REAL GOOd and even then
it likely doesn't contain all variants people may want.
All places were already consistently using "expected to <stuff>"
describing expectations backed by assertions, except for the Primitives
library. Fix that, plus random other doc fixes.
And also immediately document it's not recommended to be used if it's
important to not miss any events, so basically next to useless. Yet some
projects implement their own key state caching on top of
Platform::Application, so it's better to give them the builtin thing
than suffer needless wheel reinvention.
And then std::tie() into mutable variables that are easy to get out of
sync. Just don't. No.
Interesting is that STL vector's emplace_back() doesn't accept the
arguments directly. Not sure why, but I'm going to drop the std::vector
next anyway.
And for the new half-float literals add a deinlined variants. I know,
it's worse than having it inline, but you're already suffering by using
this compiler at all so it doesn't make it that much worse.
Unlike _rgb and _rgbf these are not constexpr, but I'll eventually add
table-based constexpr variants into a new ConstexprLiterals namespace
for all sRGB and half-float variants.
Improve related links for the literals, and don't say "calls" because it
doesn't do that anymore, and it'd imply it inherits the same issues with
not checking for hexadecimal colors or not checking length.
This means I don't get the parsed number as an integer but have to parse
it myself from individual chars, on the other hand it allows me to check
that it's indeed hexadecimal and has correct length, because writing a
24-bit color literal with _rgbaf, or forgetting one digit, etc. was a
common source of accidental bugs.
The new code is larger and more complex, so I verified that it doesn't
have too large effect on compile times. On GCC the MathColorTest built
in ~1.20 seconds before and ~1.25 after, on Clang it was 1.24 vs 1.26.
So there's a minor increase, but it's small enough to warrant the
increased robustness. In total, the whole codebase with tests builds in
~120 seconds both before and after, so I suppose unless the codebase
consists of just color literals alone (which could be the case for e.g.
some stylesheets), it's completely fine.
And it found bugs in some test code already. Fix for those is in next
commit.
The original behavior was extremely imprecise. I remember hitting this
in the UI library, where it was happily telling me that a vector is
zero, and I spent ages debugging only to replace it with an equality
comparison that behaved correctly. Let's fix that properly.
Not file contents yet because the file can start with a XML preamble,
seven megabytes of comments and only then there's <svg. I'm not in a
mood for that today.
Counterpart to GlyphCacheArrayGL. At first I expected that it'd need
TextureTools::DistanceFieldGL to be expanded with texture array support
but after enough massaging of brain matter I realized that not really,
since the procesing has to be done slice by slice anyway, and having to
upload the whole array just to have a temporary input for processing
would be a waste of memory.
It just binds a layer of it to a framebuffer internally so no shader
changes or extra construction flags are needed. Originally I thought
about making the input an array as well, but ultimately that just
doesn't make sense -- the processing would need to be done slice by
slice anyway and you don't want to allocate the whole excessively sized
texture just for it to be used once, and only a part of it every time.
At first I was like "ugh this is BAD" and made the texture and output
framebuffer resident. Then I realized that for the upcoming array
variant I need to reattach the output texture every time, so having a
resident framebuffer was not that useful anymore, and then I realized
that having a resident texture but calling setImage() on it is not any
better than making a temporary one every time, and making the resident
texture significantly larger just to accomodate any size that could
possibly be processed was even worse. So, ultimately it's just these
comments.
Vladimír Vondruš