That just makes no sense, as one then has to explicitly call disable()
to not have printStatistics() produce a useless line in the output.
Also have the same behavior also if it's constructed or set up from an
empty list of measurements, since that should be equivalent.
This makes the test added in previous commit pass on Chrome. This also
fixes the UI library there now, before it didn't show icons exactly due
to this, because they're uploaded with a non-zero offset (after text
glyphs) and Chrome requires the image height to be set in that case even
if uploading to the very first slice.
It works everywhere except on Chrome WebGL 2, which complains that pixel
unpack parameters are incorrect. Which is a very helpful error on its
own, fortunately I know already where the problem is.
Like, no wonder C++ codebases are so bug-ridden, given all APIs in the
standard library are weird like this, requiring the user to completely
understand their inner workings in order to be able to use them safely.
A fix for this got made in 390d3fc06f
(2022) already, but somehow the corresponding tests were living in a
half-done stash ever since. I should probably also just do my own binary
search thing so I don't need to test everything so extensively.
Unpack skip / row height parameters aren't supported there but alignment
is, so be sure to test that. Together with discovering some extremely
weird behavior, likely some shitty ANGLE bug.
I thought this would fix a leak reported by ASan when running on Mesa 25
llvmpipe, but it didn't. Given that no leak is reported when *not*
running on llvmpipe, I assume this is llvmpipe's fault.
This likely originates in pre-2018 state of the repo where the GL
wrapper was part of the main library and CompressedPixelStorage wasn't a
thing on ES simply because there was no such extension.
These are all just minor off-by-one errors, nothing to worry about.
Except maybe for that one case with MeshTools::compile() but the rest of
the image renders fine, so it's not like I'd have some critical issue
there.
It worked correctly with local testing, but now I enabled llvmpipe for
(desktop) GL testing on the CI where it's compiled with GCC 4.8 and *of
course* image.release() gets called before image.size(), resulting in
empty image being produced.
I bet the same happens with MSVC, it's just that nobody discovered yet.
So it's clear the error comes from Magnum and not something else. Also
unify these and make GLFW not report the error on two lines if the init
fails.
Ugh, except that glfwGetError() is only there since 3.3, so I have to
keep the old code as well.
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.
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.
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.
Vladimír Vondruš