This code path is not run there due to the newly added
"intel-windows-broken-dsa-for-cubemaps" workaround, but in case someone
disables it for testing purposes the code should not randomly blow up on
an assertion in compressedPixelFormatPack().
The image() queries were using getCubeLevelParameterivImplementation()
but the subImage() were inherited from AbstractTexture, using a slightly
different implementation. Since we'll need to apply workarounds to all
cubemap APIs, this needs to be consistent.
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.).
Fixing the new (and now failing test) from the previous commit. 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). Reordering the two
operations fixes it.
In comparison to how this was meant to be done in the original
169031fb7b, the new way should do the same
but additionally avoid a bunch of redundant state calls. Let's hope no
more bugs related to this appear.
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.