Remove the canvas renderer addon

[Tyriar]

Context from #4737 (comment)

some history on that is that years ago, back when the canvas renderer was built in to the core, we wanted to remove it completely to reduce maintenance overhead. We ended up keeping it pretty much exclusively for the cases where the webgl renderer would not work like some Linux setups, VMs, iOS/Safari. The case of Safari not supporting webgl2 was the biggest of these which made us instead split canvas into an addon which reduces code loading unless the user opts in or falls back to canvas.

But since #4605 and its follow ups, plus the fact that webgl2 has shipped in Safari/WebKit, I think that covers all our bases. So we could rip out the ~1-2k lines of code and also move the shared renderer code in core into the addon (which probably won't reduce core bundle size but it will simplify things).

We should remove the canvas renderer in the next major version to reduce maintenance overhead.

[jerch]

Oh dear - it happened. RIP dear canvas renderer...

[davidfiala]

Apologies for commenting post-facto. I had missed the fact that canvas was going away or I would have written sooner.

In my use case, I depend heavily on canvas renderer as I find that it provides several benefits over web GL. Before getting too deep in to it, I'd like to test the waters to on whether it's open to discussion keeping canvas alive.

To provide context to any other readers: I'll briefly note that canvas has served as a strategic middle point between the HTML renderer and something more performant. HTML rendering lags on performance, memory usage, and rendering accuracy (compared to the optimized addons). HTML renderer is generally untennable for any large quantity of text. Canvas solves this problem. WebGL addon does too, but comes with caveats.

WebGL uniquely presents some interesting challenges which I think make it questionable for production use in some cases:

1. Maximum 8 to 16 webgl contexts (AIUI) per unit origin (?). It may vary across browsers, platforms, versions. I'd need to experiment.
2. WebGL context loss requires intervention, and can and will occur at any moment, entirely outside of your control.

For many products, tools, and myself, it's very reasonable to have more than 8-16 live terminals on an origin.

Mission-critical applications are written in HTML+JS these days. Unavoidable. This may seem like a hyperbole, but: The loss of a terminal mid keystroke is /like/ a power-out happening on your serial-connected emergency console during an incident. WebGL crapping out on you, or suddenly becoming unavailable... is unacceptable for an SRE-type or even a SWE doing a mission-critical task.

Our largest companies tech companies (myself a former Googler knows it well) run everything in a browser, as does vscode. So, I'd love to see whether we could investigate what a world would look like if we did maintain both canvas and webgl, as I believe that canvas provides critical stability (and performance) when it comes to the risk of sudden webgl outage /or/ limits being hit.

I know it's a hassle to maintain both GL and Canvas. Thanks for your time and consideration. Happy to conitinue discuss, regardless of outcome.

[Tyriar]

@davidfiala the dom renderer is actually way faster now than it used to be. That's why removing it was being considered again to begin with.

The issue with keeping it around is that I end up having to waste time maintaining it and any feature implemented needs to be considered for 3 different renderers. It also had some serious design flaws, such as cells not being able to draw beyond their line which means for example that underscores could become completely invisible.

Additionally I'd like to eventually port the webgl one to webgpu but definitely wasn't going to attempt that only to them maintain 4 implementations.

For the context loss issue there are hooks to listen for that and handle it, you shouldn't be facing data/connection loss as it's just the renderer that needs to be switched. I'd like this to be handled as smoothly as possible so if you have ideas to make it better I'd love to hear them. VS Code has these same gl context limitations and I haven't heard any complaints for a long time after the initial fixes to context loss handling.

[davidfiala]

Thanks for the note, @Tyriar. I totally understand the challenge, and empathize with the difficulty of multiple impls.

Re DOM renderer: I think one problem I ran in to was that keeping a substantial amount of scrollback was a big showstopper. Maybe it is better and I just need to try again. Does DOM renderer add scroll history on-demand, or leave it permanently in the DOM? (to be fair, it sounds hard to accomplish on-demand history loading/unloading)

I'm assuming that vscode is using the webgl renderer by default?

In vscode: I loaded up a bunch of terminals all running a constantly-changing visual app. In this case cmatrix. Once you hit a certain number of terminals, old onest ones die out as you open new ones:

The broken panels do come back in to existence eventually. But it makes me wonder: How? If loading more than 16 panels or so causes oldest to crash (presumably due to context loss), is it just grabbing another context? Is the one it "stole" a context slot from.. also crashed now? Are they just ping-ponging around between 16 slots many times a second? I'm not sure yet- I can definitely experiment more.

--

Back to your original request for ideas: Here's a brainstorming question.... Could xtermjs be aware of multiple instances of itself, and multiplex a single GL context to render all live instances? ie, with 1 context, write N different terminals to N different output locations? ;) Sorry if this is an uninformed idea... I'm not very familiar with webgl.

[jerch]

Back to your original request for ideas: Here's a brainstorming question.... Could xtermjs be aware of multiple instances of itself, and multiplex a single GL context to render all live instances? ie, with 1 context, write N different terminals to N different output locations? ;) Sorry if this is an uninformed idea... I'm not very familiar with webgl.

Hmm I wasn't aware, that browser engines restrict gl context usage to those low numbers (btw they also do this for audio context, which for some reason I was aware of...) To me your idea seems to be the only "workaround" in the long run.

But note that this will be rather cumbersome to achieve, as it would involve a global (as of js-context-wide) driver-like manager dealing with the scarce gl resource. xterm.js makes heavy usage of texture RAM from the glyph cache, which ofc will see even worse thrashing behavior, when shared across several terminals at once. (Idk how browser engines deal with that on the level of separate gl contextes, whether they have access to faster blitting primitives than webgl offers etc)

@Tyriar Could we learn here from other highly integrating 3d libs like three.js? Do they have a global gl manager?