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.
The Audio::Extension::extensions() and GL::Extension::extensions()
functions now return an ArrayView instead of a reference to std::vector.
Having a function-local static std::vector is the worst thing ever. Ugh.
Not sure what I thought here, but using GL_IMPLEMENTATION_COLOR_READ_*
with glGetFramebufferParameteriv() is possible only since GL 4.5
(there's no extension adding it) and there's no equivalent for it in
GLES 3.1. I assumed that since the entry point is defined in 3.1 then it
would also accept the same enum, but apparently not -- and this
inconsistency is not fixed in 3.2 either.
Funnily enough, all drivers I tried (Mesa ES, SwiftShader, ANGLE) were
accepting this. The first driver that complained was ARM Mali on Huawei
P10 and there I assumed a driver bug -- but on the contrary, this is the
only driver following the spec properly :)
Now the glGetFramebufferParameteriv() API (and the DSA equivalent) is
used only on GL 4.5 contexts and up, everywhere else it's done using
the old-style glGetInteger(). I also renamed the implementations to not
misleadingly mention ES 3.1, since it has nothing to do with this. The
code path dispatch code is a bit entangled due to all the workarounds,
hopefully not breaking any behavior that worked before.
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.