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.
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.).
Well, only for CMake 3.13 and newer, by using the SHELL: variant of
INTERFACE_LINK_OPTIONS. In order to stay compatible with older versions,
it needs to be done in FindMagnum.cmake and modifying the global
CMAKE_EXE_LINKER_FLAGS. This case was updated to work properly also with
CMake subprojects.