In particular, the usual setStorage() + six times setSubImage() wasn't
really tested anywhere except in fullImageQuery(), which usually fails
for other reasons anyway. Also testing more than just +X, since SOME
DRIVERS apparently fail with other coordinates.
If building with deprecated features enabled, the buildsystem checks if
the option is still set and is inconsistent with what Corrade reports
and reports a deprecation warning. For backwards compatibility the
MAGNUM_BUILD_MULTITHREADED CMake variable and preprocessor macro are
still provided as well.
Instead make use of the ArrayView STL compatibility. To avoid breaking
almost all existing code the Corrade/Containers/ArrayViewStl.h header is
included implicitly when MAGNUM_BUILD_DEPRECATED is defined, but this
will get removed in some future release to speed up the compilation.
Interesting that I didn't run into this until testing on Mesa AMD
drivers. So far it worked for NV, Mesa Intel, Intel Windows, Android and
many more. Heh. Also improved the test to actually verify the user
pointer gets passed through correctly and updated the docs to reflect
this behavior.
Would fail on an incomplete framebuffer error on framebuffer-less
windowless contexts. Didn't happen before, I think it's because of a new
check in a new Mesa.
These tests need to use MagnumGLTestLib, however the Application library
they're using is linked agaist MagnumGL. This causes problems at least
on Windows with GL::Context::current(), where the affected two tests
(GLMeshGLTest and GLBufferImageGLTest) failed with current() having no
context.
Deprecated for 2018.04, it's been almost a year since. Whoever is using
Magnum regularly updated already, and who not can always upgrade
gradually (2018.02, 2018.04, 2018.10, 2019.01 etc.).
This one crashes. Turns out the 169031fb7b
contained a random temporary test state instead of the real solution
(and so the comment didn't even match the code, it should have been
resetting that to 0). That also made some tests fail with DSA disabled,
but none of the tests were actual Mesh tests, just accidentally hitting
the problematic code path.
I took the opportunity to look at this more closely and investigate
*why* this failed -- turns out, in setIndexBuffer(), I was resetting
the state tracker to a VAO state that was about to be set in the very
next step, and then, when doing that next step the state tracker
"optimized away" the state change because it thought it was already done
(even though it wasn't). The new test in MeshGLTest covers this
particular case.
What's left is *a lot* of places taking monstrous
std::vector<std::reference_wrapper> and that can't be changed to
std::vector<Containers::Reference> in a source-compatible way. Even that
would be only a temporary change, since the goal is to fully avoid
dependency on STL in those cases.
The final version of these APIs should take
Containers::ArrayView<Containers::Reference> and be implicitly
convertible froom e.g. std::vector<Containers::Reference>. That's
definitely possible, but not in time for 2019.01, so instead of forcing
users to temporary pass a `{vec.begin(), vec.size()}` everywhere instead
of just `vec`, I'm rather keeping these APIs intact.