Context cleanup

[tsherif]

This is in preparation to move context creation utilities into gltools.

The biggest change is that createGLContext no longer attempts to create a headless context. To simplify testing, I've moved createHeadlessContext and createTestContext into test-utils.

Other smaller changes:

• getPageLoadPromise is now a method on AnimationLoop, the only place it was used.
• WebGL2RenderingContext and Image polyfills are in webgl/init (don't love this as place for them).
• Removed setContextDefaults and destroyGLContext as the former can easily be managed by the application without setting global state, and the latter only handled headless cases and wasn't actually used anywhere.
• Got rid of the re-exporting of WebGL types as they were only used in a couple of places that were more easily handled by a few eslint rules.
• Deleted a large wip folder in test/apps/.

[coveralls]

Coverage decreased (-4.2%) to 61.393% when pulling 2d46458 on context-cleanup into c2047d6 on master.

[ibgreen]

Looks good. I like that we move the headless dependencies code out of the "production" modules, but still keep some support for testing.

If someone wants to use headless in production, I assume it is still possible for the app to import headless gl and call instrumentContext? Is it worth mentioning that somewhere?

This is in preparation to move context creation utilities into gltools.

Thanks, great prep diff that allows an observer like me to track the changes.

Just a thought: is your ambition to keep all code that annotates/modifies/instruments the gl context inside gltools? I don't recall exactly but there might some of that inside the webgl module. If it was possible to keep that complexity inside one module, that would be a good thing...

[tsherif]

I assume it is still possible for the app to import headless gl and call instrumentContext

This is how I did it for luma's testing: https://github.com/uber/luma.gl/pull/1298/files#diff-ff7a789f8c4b8ed72b4cf337a0102c19R23-R29

Is it worth mentioning that somewhere?

Good call. I'll make a note to add something to the developer guide or maybe in the "low-level" tutorial.

is your ambition to keep all code that annotates/modifies/instruments the gl context inside gltools? I don't recall exactly but there might some of that inside the webgl module. If it was possible to keep that complexity inside one module, that would be a good thing...

I think so. A lot of this was in the "context" part of the webgl module, which I'm hoping is now simple enough to move to gltools without much trouble. Other than that I'm not sure what fits. Maybe also the environment checks like isBrowser, isNode. Those are pretty light and would be handy at the lowest levels.

[ibgreen]

the environment checks like isBrowser, isNode. Those are pretty light and would be handy at the lowest levels.

Yes. Aldo those are duplicated in basically all our repos. At one point, had created a wip probe.gl/env module for sharing these but it got cut at some point.

But that is borderline, it is nice to share these, but also nice not to have to have a dependency for such a basic thing. Though there are some more sophisticated things like isElectron that we probably don't want to duplicate.