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.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Using a tuple was very useful, helpful and exciting as I had to make an
explicit comment about what element is what, and then having to remember
the order in all places that accessed the tuple.
Using a struct however is rather boring as the fields are just named
there, I don't need any complex std::get<4>() and extra comments
explaining what is where and it's just not so adventurous anymore. The
build time of a non-deprecated MagnumGL library also dropped from 5.9
seconds to 5.85. SAD!
All the tests were updated to explicitly check that non-null-terminated
strings get handled properly (the GL label APIs have an explicit size,
so it *should*, but just in case). Also, because various subclasses
override the setter to return correct type for method chaining and the
override has to be deinlined to avoid relying on a StringView include,
the tests are now explicitly done for each leaf class, instead of the
subclass
The <string> being removed from the base class for all GL objects may
affect downstream projects which relied on it being included. In case of
Magnum, the breakages were already fixed in the previous commit.
Compile time improvement for the MagnumGL library alone is 0.2 second or
4% (6.1 seconds before, 5.9 after). Not bad, given that there's three
more files to compile and strings are still heavily used in other GL
debug output APIs and all shader stuff. For a build of just the GL
library and all tests, it goes down from 28.9 seconds to 28.1. Most
tests also still rely quite heavily on std::stringstream for debug
output testing, so the numbers still could go further.
This used to somehow get dragged along with <string> on all platforms we
tested on, but once we get rid of <string> we'd have to include
<algorithm> instead. Not acceptable, also it's much shorter and less
error-prone this way.
It's quite easy if WEBGL_debug_renderer_info is present, but if it isn't
then our only hope is to check for ANGLE-specific extensions. Which may
cause some false positives, but since we need to enable various
workarounds for ANGLE to avoid issues, it's better than having the
detection too conservative.
The original ANGLE detection based on line size is probably not so
relevant anymore, but let's keep it there.
The type is now extended to 32 bits. In the GL and Vk libraries it means
one can now do things like
MeshIndexType type = meshIndexTypeWrap(GL_UNSIGNED_BYTE);
and passing that to GL::Mesh or Vk::Mesh will cause it to use the value
directly, instead of doing a mapping from a generic type. The *real* use
case for this is however to allow custom index buffer representations in
Trade::MeshData. Support for that will be hooked up in the following
commit.
It may soon start happening that those will have an
implementation-specific value that is neither a GL or a Vulkan
identifier, so people should not just pass them around without checking.
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.
Looking at the snippets, these seem to have been written back when there
was no builtin shaders yet, it seems, not to mention
MeshTools::compile(), Trade::MeshData or any of the other high-level
APIs. Rather overwhelming to just throw huge code snippets at the user,
explaining a workflow with a custom-made mesh that's going to be drawn
with a custom-made shader, which is like level 999 of using the GL
library.
Because its usage is rather specific, there wasn't no
extension-dependent dispatch happening and thus the extension was never
marked as used. But that was confusing since it actually is, so add an
explicit branch just to list the extension.
It was used just for certain corner cases that weren't covered by
{EXT,OES}_draw_elements_base_vertex already, but because of a wrongly
understood extension interaction the EXT/OES multidraw entrypoint (which
isn't implemented on ANGLE) was used from these as well.
And while trying to disable the two extensions for the MeshGLTest I
discovered the test half-expects the ANGLE variant to be implemented and
so I finished it for both the single-draw and multi-draw case.
The extension interaction that makes base-vertex multidraw calls broken
on ANGLE will be fixed in the following commit.
Yes, this is only ever provided by an ANGLE extension, and as you might
have guessed, The Great Google Overlords didn't bother caring to have
this supported outside of their browser.
Since the main point of the low-level API is to make use of the
EXT_multi_draw_arrays / ANGLE_multi_draw / WEBGL_multi_draw extensions
for a reduced driver overhead *and* the builtin gl_DrawID variable, it
just doesn't make sense to provide a fallback to draw() in a loop. When
the extensions are not available, the user has to do extra work in order
to supply proper UBO draw offset for each draw call, and thus the
fallback path has basically no practical use.
On the other hand, draw() taking the MeshView instances is kept as-is --
this one is rather old and so breaking compatibility would be an
unnecessary pain point. Plus, since it has to allocate the contiguous
arrays internally, it's not desirable for any fast-path rendering
anyway.
Vladimír Vondruš