For some reason it had the full set of elements on ES2 as well, i.e.
something that definitely shouldn't be the case. Unfortunately C doesn't
warn if the array isn't initialized for all elements, setting the
remaining to 0, so this was uncaught until now. Now if I accidentally
make the array too small somewhere, it'll blow up inside
BufferState.cpp.
Because I had a stupid bug in the test and wasn't testing all of them.
And then the function itself had a bug that made it no-op exactly when
it shouldn't be a no-op.
Somehow I overlooked this extension back when implementing multidraw, or
maybe it was intentional because ANGLE supported multidraw but not this
extension.
The macro, which is enabled when preprocessing the headers for
single-header libs, excluded the TypeForSize specializations, making
these two not work with Math::gather() and Math::scatter(). It's done
correctly in Vector2 and Color, not sure why not here.
Causes the following warning on GCC on a static build if user code isn't
compiled with -fvisibility=hidden:
warning: ‘Magnum::GL::Mesh’ declared with greater visibility than
the type of its field ‘Magnum::GL::Mesh::_attributes’ [-Wattributes]
According to quick testing, given that the struct definition isn't
public, presence of the MAGNUM_GL_LOCAL has no effect on the symbol
being exported. On the contrary, inner classes that are meant to be
exported (such as the ones in GL::Framebuffer) have to contain
MAGNUM_GL_EXPORT, otherwise it leads to linker errors. Furthermore, all
other inner structs with local definitions holding PIMPL state and such
don't have a MAGNUM_*_LOCAL macro applied anywhere
Thus the macro was likely redundant, and is removed.
I thought I went over all these several years ago already, but
apparently not or maybe back then not all websites were HTTPS-ready. Now
they mostly are, except for maybe one or two.
I need this to sample a color map for debug visualization in the UI
library. Thus so far it's just 1D, and with 8-bit input. Other variants
might get added in the future if needed.
It's faster that way because it doesn't involve a linear lookup, if the
resource is already imported it's a constant-time check and it becomes a
no-op.
Technically speaking there are many more opportunities to mark things as
C++14 constexpr, such as various operators, but doing so would make them
impossible to optimize with various (SIMD) intrisnics unless basically
providing two separate implementations for them, one scalar, slow and
constexpr and the other fast but not compile time, and dispatching with
std::is_constant_evaluated() or some such from C++20.
In other words, such functions cannot and will not be marked as
constexpr in C++17 or older anyway, because the preference is and still
should be runtime perf rather than doing excessive work at compile time,
where it's hard to debug or reasonably test etc etc., and the more you
rebuild the more you'll hate the cost of extra compile time caused by
that.
Co-authored-by: Stanislaw Halik <sthalik@misaki.pl>