It's used only there and only to supply a silly argument to a broken API.
Unfortunately back when adding this utility in 2015 I didn't document
what was it for, which initially made me think it's there for some
suspicious reason. Well, the reason is suspicious, but for an entirely
different reason.
Not sure why this wasn't a problem in Corrade, maybe because here the
clang-cl build doesn't run GL tests and so while there the } lines were
marked by it as covered (instead of being ignored), here they're marked
as uncovered and all other jobs ignore them?
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.
This means SwiftShader is only used for Mac ES3 build and Android.
Also remove the parallelism and --output-on-failure, it's unhelpful as
it only leads to less information being provided if the CI fails.
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.
This apparently works well for quite some time (this is Ubuntu 18.04,
after all!), I just didn't know because the build defaults to GLX which
doesn't work headless. So, yeah, code coverage, here I come!
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.