Originally (2012? 2013?) I expected that there would eventually be
OpenGL ES 4.0, thus it made sense to differentiate between ES2, ES3 and
something else ES yet unknown. But as ES4 was increasingly unlikely to
happen, the internal code treated MAGNUM_TARGET_GLES3 as a simple
inverse of MAGNUM_TARGET_GLES2, and only in a very few places,
only adding confusion.
Thus it's now deprecated and defined as a simple inverse of
MAGNUM_TARGET_GLES2 on MAGNUM_TARGET_GLES builds, and none of the
internal code uses it anymore.
This one was spectacular -- ALL uses of it had also #include <tuple> in
order to std::tie() the result into separate major & minor variables. So
much compile time overhead for so little.
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
The web isn't broken enough yet, apparently. Support for both of those
extensions was added in early 2020 (and I think I remember even seeing
them listed as supported in some browsers), one of them was renamed
mere two months later, one in January 2023.
And I discovered just by accident, the browsers *of course* don't even
bother advertising both to have some transition period. Or maybe that
transition period happened, for 3 weeks in January, and if some
developer didn't notice in that time, "it's their fault". Or maybe it's
my fault, for attempting to use an extension that was stuck in a "draft
status" for four years. THE WHOLE WEB IS EITHER IN A "DRAFT STATUS" OR
"DEPRECATED", THERE'S NOTHING IN BETWEEN, FFS!
Constant needless churn, UGH.
The glDepthRangedNV() and glClearDepthdNV() behave differently from
glDepthRange() and glClearDepth() -- they don't clamp. There doesn't
seem to be any change in recent GL related to this, so this extension is
still valuable for improving depth buffer precision. Or, alternatively,
it's possible to use the glClipControl() API from GL 4.5 to achieve the
same.
To match ARB_texture_view from from GL 4.3. Not sure why there's two of
them -- I was looking into the spec files, and the EXT variant seems to
be based on the OES variant but doesn't seem to add any change (or, no
change is listed), however the OES variant has number 218 while EXT has
185 so it's actually newer?! No idea what's happening there.
And this, this change allows the growable Array to use malloc() instead
of new, and thus also realloc(), saving unnecessary reallocations if the
memory can be grown in-place. All because Containers::Pair is trivially
copyable while std::pair wasn't.
There isn't any good reason to use the STL anymore.
Hm, and here I used the "capability" of std::pair that allowed it to
store references. I don't even want to know what all was involved to
support that, Containers::Reference is much easier to reason about.
While branching on a compiler is rather common, checking a particular
compiler version should be needed only rarely. Thus minimize use of such
macros to make them easier to grep for.
Was browsing the extension registry looking for something else and found
this instead. It used to be ES catching up with desktop, now it's the
other way around.
It was mistakenly thought to be replaced by the EXT_color_buffer_float
(which replaces WEBGL_color_buffer_float and in addition lists both 16-
and 32-bit float variants). But since there are still those stupid
patents for rendering to 32-bit float attachments, certain hardware
supports only rendering to 16-bit and not 32-bit, so the "superset"
extension isn't enough to be able to discover which hardware can
render to half-floats.
Also updated (hopefully all) docs to list this extension as being an
option on WebGL 2 as well.
Unlike most other extensions, this one has to be explicitly enabled in
Emscripten in order to be used. Which thus done as part of other "driver
workarounds" done on startup. To avoid that, the extension can be
explicitly disabled, and thanks to the previous commit the disabling
will be performed before the extension is attempted to be enabled.
With this flag set (which is done implicitly for all windowless apps
and, conversely, not done for all windowed apps), the default
framebuffer state isn't touched in any way, which should avoid potential
race conditions with default framebuffer on another thread.
This means that instead of 12 separate allocations we have just one,
allocating everything together in a contiguous piece of memory. That
should be also a bit more cache friendly when accessing the state as
it's not scattered around the memory like crazy.
Because there are no Pointer indirections needed anymore, the State
members are just references now. That resulted in a lot of sweeping
changes around the whole GL library, but they're all trivial, changing
`->` to `.`, mostly.
There's two more nested allocations in the TextureState struct, will
take care of them in a separate commit.
I don't see a real use case for this API (and don't remember ever using
it) and it only causes extra overhead during context creation (and then
a ton of useless allocations at runtime).
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.
Needed a change in flextGL to allow merging in 3rd party gl.xml
additions because Chrome is apparently a center of the universe and thus
doesn't need to bother upstreaming its extensions, ffs.
Vladimír Vondruš