WebGL context loss handling

[juancampa]

This PR adds a helper class in WebglRenderer that manages webgl contexts. This is needed because:

• Contexts can be lost at any time if the driver decides that it needs the resources for something else.
• At least one browser (chrome) has a limit to the number of simultaneous contexts that can exist at any given time.

When a context is lost:

• if the terminal is paused: don't do anything, it'll be recreated when unpausing
• if the terminal is unpaused: try to kill a paused terminal to free up resources and recover the context immediately
  • if there are not enough paused terminals, it means we've reached the max number of webgl contexts allowed by the browser, so print a warning and give up.

When a renderer is unpaused, if its context has been lost, we simply get rid of the whole renderer and ask Terminal to create a new one.

Renderers are kept ordered by least-recently-used so that less used ones are killed first when resources are needed.

If one of the context that are being recovered was just lost, it means that we're currently at a resource limit so we need to kill a few paused renderers. if we fail to release other contexts (i.e. everything is unpaused), there's no point in trying to recover anything because we would be killing an unpaused renderers. In this case, just give up.

---

I used a class expression to have access to WebglRenderer private fields while keeping this whole thing encapsulated

[juancampa]

Testing cases

Here's a few tests I ran on Hyper. Not sure if there's currently a way to test this on the current demo page.

• Create 16+ splits in one tab (there's no endless cycle of create/destroy contexts)
• Create 16+ tabs
• Create <16 splits and then reach the limit by creating tabs
• Contexts are lost in LRU order
• Contexts are not lost unless enough terminals exist simultaneously (Chrome limit)
• Go crazy creating and destroying tabs and splits, making sure there's never a blank terminal unless we have 16+ unpaused terminals

[juancampa]

There's another approach to context-loss handling where the browser determines when to recreate contexts. I don't think this would work for us since we need control over the context recreation (to have LRU priority, for example)

[Tyriar]

This should happen automatically after dispose on the next GC?

[juancampa]

Yes, however, we force it so that another context can be created before the next GC. If we don't force it here, Chrome might not notice there's an available context and could kill an active one.

What I observed is:

1. open 20 tabs (the first 4 will lose their context)
2. close the last 16 tabs
3. close one more tab
4. result: Chrome will warn that the max number of contexts has been reached
5. expected: no warning

So, it seems like one of these is happening:

1. GC is not firing during the closing of the 17 tabs
2. GC isn't collecting the underlying webgl contexts (maybe it's lazy by design?)
3. Someone's keeping a ref to this instance, preventing it from being GC

I'll grab a snapshot to make sure (3) is not happening

[juancampa]

I can confirm all webgl contexts are eventually GC'd. But we still need this to prevent Chrome from killing the oldest context (as opposed to the LRU one)

[Tyriar]

Could you pull this into WebglContextHelper.ts?

[Tyriar]

Not supported in Chrome? https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_lose_context/loseContext

[juancampa]

Nah, that seems outdated. It's definitely supported on Chrome and Chromium: https://codesandbox.io/embed/xpjjjmn1oq?view=preview

[Tyriar]

Need the refactor to pull WebglContextHelper into its own class before merging this, this will involve breaking WebglContextHelper's dependence on private members of WebglRenderer. Also there are some lint issues that need to be fixed too.

[Tyriar]

Closing off in favor of xtermjs#2253