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.
These are in most cases the only strings that are used, and I don't
think having to call std::strlen() for each of them is a good idea if
we don't need to.
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.
Caused an error when creating a WindowlessGlxApplication on a Mesa with
just llvmpipe. Note to self: never again try to fix anything related to
Xlib that's not broken.
This reverts commit 511d0c1b27.
Looking at provided FBConfigs, first few of them are pbuffer-only so why
not just pick those already, we don't need to look for some config that
supports rendering to a window.
Similar change to the windowed apps, also resetting it when core context
creation fails or when the workaround is applied. This change is not
done for CGL, iOS and Windows EGL apps, as these are either GLES-only
or, in case of macOS, such flag is not available.
Detected in WindowlessWglApplication, added it to both Sdl2Application
and WindowlessWglApplication. Renamed the workaround to reflect that it
is for all three major vendors.
Each Windowless*Application has now a companion Windowless*Context that
manages just the GL context creation and nothing else, with the ability
to just create the context and not make it current, so it doesn't affect
current thread state and can be moved to another thread and make current
there.
Other things that were done:
* Using `NoCreateT` instead of `nullptr` for creating the application
without creating GL context.
* Properly handling failed creation of Magnum context instance -- if it
errors out, also the GL context is destroyed to make it possible to
create the context with a different configuration.
* Reworked AMD and NVidia binary driver workaround, where core context
created with specific version doesn't automatically choose the newest
available (creating compatibility context on the other hand causes
the version to get stuck on 2.1 on Mesa and OSX).
* Added the above workaround also for WindowlessWglApplication to avoid
driver issues in the future.
* Reworked WindowlessWglApplication to not be so crazily entangled. It
was a misunderstanding on my side about how WINAPI works. Much
simpler now (and I hope still working :D).
Binary AMD drivers require the user to explicitly request the debug
context on context initialization, otherwise all debug functions are
no-op. This allows us to use debug functionality in command-line utils
and, mainly, GL functionality tests.
The Windows versions are coded without testing, so I hope I did not break
something :)
The parameterless Platform::Context::Context() constructor and
Platform::Context::tryCreate() function are deprecated in favor
functions that take argc/argv pair. The Context class now accepts
arguments starting with --magnum-* prefix. Currently there are none
except for the implicit --magnum-help, but that will change with the
following commits.
AMD is behaving the same as NVidia (at least on Windows) -- when
creating core context with minimum specified version set to 3.1, it
forces that version instead of going with the largest available version,
which, again, is pretty useless behavior.
Enabling that on both Linux and Windows, the behavior is confirmed on
Windows but I bet it's doing the same on Linux.
In some cases the GL context creation might success without error, but
the created version is one that we don't want (e.g. software GDI
rasterizer on Windows). Previously the Context class constructor just
exited the application and it was impossible to react on that from the
application side (for example reducing some context feature
requirements).
Now there is Platform::Context::tryCreate(), which returns either
created instance or `nullptr` if the instance creation failed with some
error. That is now used in all Platform::*Application implementations.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Currently XEglApplication and GlxApplication were requesting only ES2
context and SDL2 was not requesting anything in particular (but in
theory should work on ES-only systems flawlessly). Now explicitly
requesting ES3 if MAGNUM_TARGET_GLES3 is enabled and also explicitly
requesting ES in SDL2, so it is usable also with
MAGNUM_TARGET_DESKTOP_GLES.
Somebody would just want to defer context creation after parsing
arguments or doing some validations without any particular setup, thus
having to write even the {} is annoying.
Vladimír Vondruš