Somehow I overlooked this extension back when implementing multidraw, or
maybe it was intentional because ANGLE supported multidraw but not this
extension.
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 don't think my ancient Doxygen fork is aware of [[nodiscard]], and
it's quite clear that the return value is important when looking at the
docs, so just remove it from processing.
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.
Yet another broken behavior with compressed textures on NVidia unearthed
by the recent changes with compressed block properties being set almost
always.
Text only, SDL3 has support for arbitrary mime types so the API is named
clipboardText() and not just clipboar(). Wanted to add this for
Emscripten as well, but after looking around a bit, I don't think I want
to deal with that until someone actually wants clipboard support
somewhere.
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.
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.
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.
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.
Wanted to add a proper variant that reads all layers at once into an
Image3D, but that requires the Image APIs to be made less crappy first.
So it's just this for noew because now I badly need it for
Text::DistanceFieldGlyphCacheArrayGL tests.
I fixed some minor English crimes in the method docs and then realized
this is all just bad and the utter uselessness and lack of information
led to way too many confused questions over the years. So let's do it
properly, finally, ugh.
Vladimír Vondruš