Check for WEBGL_provoking_vertex extension

[mrxz]

Depending on the exact system configuration, the preferred provoking vertex convention might differ from the WebGL/OpenGL default. This can be communicated by the browser by exposing the WEBGL_provoking_vertex extension. In other words, the presence of this extension itself indicates it's worth changing the provoking vertex. This PR checks for the extension and sets FIRST_VERTEX_CONVENTION_WEBGL if present.

Going by the Web3D survey data (https://web3dsurvey.com/webgl2/extensions/WEBGL_provoking_vertex) this is relevant for the vast majority of Windows and Mac and iOS devices. Testing on a Windows laptop did show a really nice jump in performance.

This only applies when using flat interpolation in shaders, which Spark does. Since these values should be the same for each vertex, changing the provoking vertex makes no semantic difference. That said, it is a global configuration, meaning other uses might be impacted if they rely on flat interpolation picking the last vertex.

[asundqui]

Fantastic, nice find and improvement. I guess it's possible some user might have an issue if they have special shaders that needed it to be the last vertex, but it would be in their interest to change it to use the first. Awesome that it has a measurable improvement in performance.

[mrxz]

I guess it's possible some user might have an issue if they have special shaders that needed it to be the last vertex, but it would be in their interest to change it to use the first.

Yeah, I'm not too fond of having side-effects in the SparkRenderer constructor, but in this case it seemed the most convenient. I did contemplate alternatives like only warning the user if detected, but realistically that would only serve to increase the "bloat" needed to properly use spark (as in, each example would then include this snippet).

In the rare case a user does use a custom shader that depends on the provoking vertex being the last, they can still manually revert the setting after constructing the SparkRenderer. Though as you said, its in their interest to change the incompatible shader/mesh instead.

Awesome that it has a measurable improvement in performance.

This honestly surprised me a bit. On the Windows laptop I had an example hover at ~76fps before the change, and ~88fps with the change. My naive understanding was that a mismatch in provoking vertex would force ANGLE to reorder the index buffer. Given that the SplatGeometry is just an instanced quad, that shouldn't be too expensive, though it seems there's possibly more going on.

Haven't tested on other devices/configurations, but it should be a net positive, otherwise the browser isn't supposed to expose the extension in the first place.