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.
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.
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.
Vladimír Vondruš