Also test it properly and add a check for extension availability. Sigh,
seems like nobody ran this test on an Apple device since this thing got
added in 75d238f50b ...
Its only use was for specifying N-dimensional SamplerWrapping because,
compared to a Math::Vector, it had an implicit constructor from a single
value (whereas the Vector has it explicit). I solved that by simply
adding a few single-value overloads where it mattered. There, done. No
need for this weird thing and confusion with Containers::Array anymore.
All places that used it now use Math::VectorN<SamplerWrapping>, but the
class is still included for backwards compatibility purposes, together
with providing implicit conversion from and to a Vector.
Ah the good old times where my brain was not overflowing with
unnecessarily deep knowledge about how GPUs (and OpenGL drivers in
particular) work. Nope, switching a blend state and calling glFinish()
won't generate any GPU work, that will be all deferred until there's
something to be actually drawn, cleared or copied.
Disabling engine startup log or modifying enabled extensions /
workarounds from the application side was one of the common pain
points and this should *finally* solve the problem. This Configuration
is now inherited by the usual Platform::*Application::GLConfiguration /
Platform::Windowless*Application::Configuration classes people are used
to, so for the end user it's just as if these classes got a bunch new
options.
Having this, I also extended the ContextGLTest to verify that the
Configuration and command-line options do what's expected because that
hadn't automated tests until now. The test is mostly a copy of what I
did for Vulkan already, nothing special. Additionally all
Platform*ApplicationTest executables gained a new --quiet option to
verify that the GL::Context::Configuration subset gets correctly passed
from the Application code, because that's something we can't really
verify in an automated way.
We're going to eventually include this class in all Application classes
(need that in order to inherit a to-be-created Configuration class) and
the <string> and <vector> would be just too much. This change caused
magnum-gl-info.wasm (WebGL 2 build) to go down from 247 to 245 kB. Not
much, but that's I guess because there's still a lot other vectors of
strings elsewhere.
There's a lot more places to clean up, will do those in separate
commits. This change is the most atomic I could do, and it introduces a
breaking change to all APIs that returned a std::vector or a
std::string. Fortunately (or as I hope) those weren't used that much, so
it shouldn't cause build breakages for that many people.
Quite a lot of the optimization ideas is borrowed from the new Vk
library -- such as "interning" the driver workaround strings to avoid
allocating their copies.
Same as in Corrade. Because BUILD_STATIC is independent between Corrade
and Magnum this option is also independent -- the corner cases and bad
interactions would be otherwise too complex to handle (e.g., in case of
a dynamic Corrade and static Magnum it would be impossible to enable
this option for Magnum etc etc).