Implement OES_element_index_uint support

[dhritzkiv]

I went down a rabbit of trying to debugging why some of my glTF 2 models weren't rendering in headless mode. Turned out they were using unsigned ints for the indices, which requires the OES_element_index_uint extension. While, headless-gl doesn't currently support it, I noticed that ANGLE does.

The way I added support:

• Get the list of supported extensions from ANGLE via getSupportedExtensions (this seems to be legit, and not contain hardcoded values, as testing on different machines reported different supported extensions)
• Check to see if GL_OES_element_index_uint is in that list
• If it is, return a non-falsy value (that's all that seems to be required). As a bonus, the return value is an instance from an empty constructor called OESElementIndexUint, as that's what browsers seem to report.
• Add handling of the data to the drawElements method (if the extension is enabled and supported)

Not sure if this is the right way to add support, but it worked for me, and the conformance tests for OES_element_index_uint pass.

If this is the right way to do it, perhaps this could be done for #72, as well as other extensions?

Closes #81

[dhritzkiv]

Hmm. For some reason, the last two commits seem to be failing in CI despite their changes not affecting the tests that are failing. Tests pass locally, otherwise.

[mourner]

Hi Daniel, thanks for the contribution! To be honest, I took over the maintenance of this module to push out some trivial updates (after the original author moved on), but I don't understand much of the underlying source code. On the surface the PR looks good though. Let's try to figure out what's going on on the CI, and merge on green.

[mourner]

@dhritzkiv hey, I just invited you as a collaborator on this repo. Hopefully we can revive the maintenance of this project — this is an extremely useful repo that severely lacks core contributors.

[dhritzkiv]

@mourner Great!

What actions should I take regarding the PR? I can try poking around the CI configs to see if I can fix the tests there.

[dhritzkiv]

So I took a crack at trying to get the tests passing consistently on CI. No luck. They sometimes pass and sometimes fail. There's no rhyme or reason, and sometimes pushing the same commit again doesn't result in the same result. Some things I tried:

• using latest node and npm
• turning faucet off
• switching faucet for tap-spec

[mourner]

@dhritzkiv oh, sorry! I just realized that I had the same issue. Let's merge and try to figure out CI flakiness later.

[dhritzkiv]

Cool. Perhaps in the future we should ignore appveyor, and instead focus on the Travis builds which are running, but not connected to Github (#100)

[mourner]

@dhritzkiv made you an admin, you can now edit web hooks.

[dhritzkiv]

Thanks again! Unfortunately, it seems the repo owner is required to make changes to the connection between travis and this repo on travis

[dhritzkiv]

To clarify: it seems that travis is enabled for pushes, but not for PRs.

[mourner]

Maybe let's try changing username / token on the Travis GH hook settings page? https://github.com/stackgl/headless-gl/settings/hooks/7907966

[dhritzkiv]

I'm trying to add stackgl as a repo to my Travis account, but I need to be granted access to do so by stackgl:

Otherwise, I fear this repo won't appear under my travis account, so changing the username/token will be moot.

[mourner]

I'm not a member of stackgl so can't do that :( @mikolalysenko have a second?