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.
Strangely enough, that C4312 warning suppression now needs to be C4834
instead while I'm pretty sure it was correct back in March 2024 when I
added this in 4f7b57ffd6. C4312 is however
for "conversion of A to B of greater size", and in
4435877cf1 I was fixing a lot of those, so
maybe I just used the same number by accident and because this
particular warning is extremely easy to miss, it was never correct in
the first place? Who knows.
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>
So line code coverage reports which branches weren't taken by tests.
Other libraries need similar treatment but there's too many cases to fix
so I'm doing it just here for now.
With ARB_DSA disabled, the test added in previous commit would assert
already during bind(), and not later in label(). This was due to the
state tracker being updated too early here.
This happened to me from time to time and I always treated it as user
error. But when thinking more about it, calling wrap() without actually
knowing if the object was already created or not, is a completely valid
use case, especially in cases of making non-owning references to
existing GL objects that might only get created at some point after.
These tests now cause assertions in all cases on GLES, on desktop
some only if ARB_direct_state_access is disabled. In all cases the
assertion is triggered by querying object label (which is a no-op if no
debug extension is present, but it calls createIfNotAlready() always),
because that's the simplest, the real-world cases are usually some
texture bind() calls.
Fix in the next commits.