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š