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.
I think I tried this at least once in the past already, and failed the
same way. So just document that it's missing to prevent me from wasting
time on this again in the future.
The MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DRAW_IMPLEMENTATION() and
MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DISPATCH_IMPLEMENTATION() *is*
documented so that one stays not underscored.
Am I overdoing it? Most unpremultiplication code I found doesn't even
deal with treating alpha being zero correctly, while here I'm handling
also the cases of RGB channels going over alpha, and for packed
formats trying to match precision of the same done with pack()/unpack().
The equations were using some strange undefined `a` which made it look
like it's dealing with alpha. Just turn that into a constant like
Wikipedia does, and link there as well. Additionally, one of the `c`'s
wasn't correctly a lowercase bold vector.
Similarly as done in Aug 2024 in Corrade. When these were a part of the
function signature, they ended up being encoded into the exported
symbol. There are still cases of StridedArrayView slice() having
enable_if in the signature, which amounts to about 18 kB symbols in all
libMagnum*-d.so libraries, but apart from that this is the state before:
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
29591
And this is after. All of those are coming from STL, thus from
old or deprecated APIs that still use std::vector, std::tuple and such,
and from the few std::sort() uses.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
4103
In a non-deprecated build it's just this, which is a 10x reduction.
Can't really do much about these maybe exceút for implementing my own
swap() specializations (sigh?), but I think it's fine.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
2904
I also made it consistently use
typename std::enable_if<..., int>::type = 0
instead of
class = typename std::enable_if<...>::type
because the former works correctly also in presence of overloads and
having it used consistently everywhere makes it easier to grep & change
later. All SFINAE is now also excluded from Doxygen output, because it
doesn't make much sense there. It's better to just explain the
restriction in words than with this nasty hack.
They're not parsed since 6b22a11170
(2020), so there's no point in keeping those workarounds. They're only
kept in utility application sources as they're parsed for pages, and in
tweakable implementations where it's easier to just copypaste the whole
ifdef expression from the header every time instead of modifying it to
not include DOXYGEN_GENERATING_OUTPUT.
Because that apparently cannot work without #include <initializer_list>,
and even though that particular include is maybe just 30 lines, I refuse
to do that because it'd soon make the MagnumMath.hpp single tip over 10k
preprocessed lines again.
Fuck you, C++.
Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
So they can be used in StridedArrayView member function slicing the same
way as the mutable overloads. Pointer, Triple and other low-level
containers do the same thing and this is one of the prime use cases for
the slicing functionality, so it's silly it didn't actually work.
Which is good, those are all either anchors in the theme itself, or are
group names for which Doxygen doesn't make anchors anymore (but m.css
does). Plain HTML link still works as before, so let's do that instead.
Doxygen 1.12 has no longer a completely insane matcher and discards
those as it should. With 1.8.17 classes had to be referenced with
Corrade:: but functions, typedefs and variables didn't need to be and it
was a complete utter chaos.
Same as what Range does, so accessing them doesn't lead to weird
surprises with e.g. `.x()` missing.
Which means I can also HOPEFULLY remove that old MSVC ICE workaround
from the tests.
Same as done for Containers::StaticArray some time ago. Since it's not a
potentially dangerous operation, it's not made as an overload of the
from() function, but instead a regular constructor. It's however kept
explicit for now, even though it eventually might not need to be -- I'm
not sure about potential consequences yet.
It fixed interpolation for a more precise rounding, which means the
ground truth files for this test are now off-by-one compared to before.
In particular, nothing in the _source_ BCn data or the Y-flip algorithm
changed, it's just that they're now decoded to RGBA differently by bcdec
so the tests fail.
Worked on x86, works on ARM Linux (with GCC) as well. Not sure if it has
anything to do with long doubles being 64bit there, but I don't think it
should.
Vladimír Vondruš