[Feature] WebGL Renderer

[robertLocarno]

I'm looking at supporting shader effects similar to native Ghostty's custom-shaders config, and a WebGL renderer seems like the cleanest path. Is this something you've discussed or have on the roadmap?

I'd be happy to work on a first pass. My use case has narrower Unicode needs than CanvasRenderer (no ligatures / emoji / complex shaping), so I'd probably build a bitmap glyph atlas via Canvas 2D (looking at @xterm/addon-webgl). I'm expecting a real jump in complexity over canvas, but it seems like a pretty interesting project.

I'd be happy to ship it as a separate package/addon; just trying to gauge if this is actually worth digging into. My other option is to just use the canvas as a texture, accept the performance hit, and call it a day.

[neomantra]

What I'm about to write doesn't address "custom shaders effects", but it does set the stage for such things: I have been working on webgpu and webgl renderers for Ghostty-Web.

This is in a nm-webgpu branch built atop my nm-kitty-meow branch tracked under this WIP PR (#162).

The key first step of that nm-kitty-meow PR is to strip out the Ghostty patches as upstream has significantly improved its WASMable API surface Ghostty 1.3. So much that ghostty-web no longer needed to patch Ghostty and it was just rendering and interface concerns.

After that, I added Kitty Graphics support to the canvas2d renderer, because that was my ultimate goal with the branch. I was working on Golang Kitty TUI widgets, so I had nice smoke tests.

Next, I branched to nm-webgpu and began implementing It addressed all the concerns such as texture atlases and such. I have done this before back in the day, but this was heavily LLM-assisted. It's also not reviewed much yet, just smoke tested; at least it runs in a sandbox.

The first part of that was establishing a common Renderer interface and mapping the canvas2d renderer to that. Then I built the webgpu renderer.

After that, I spiked the first portion of a webgl renderer, where it had basic parity with webgpu using its own code. Then, as I had to address more complicated features such as Kitty Graphics, I refactored the common 3D graphics rendering into a common library. Then I completed the webgl implementation using to that internal library. The canvas2d render only uses a tiny part of the common renderering, as 3D vs canvas are different approaches.

I was doing all this work to help continue help bring TUIs to the browser, in Golang with this go-booba project. These NTChart demos were GIFs on the README, but are now live WASM demos. Press g to switch into Kitty graphics mode and click on the FPU overlay to change renderers.

https://nimblemarkets.github.io/ntcharts/demos/heatpicture-perlin/

My intent is to keep massaging this through use and to then do a deep read-every-line review, which I certainly haven't done yet.

---

I'll note that that the final evolution of this is when libghostty fully extends its rendering stack to be WASM'able. Then we can simply use that and composite RGBA fragments to our WebGPU/WebGL framebuffer. (I did attempt it, but really I didn't want to patch ghostty myself; too many dependencies still.)

However, the ghostty-web rendering stack is still important, especially for canvas2d and whatever improvements the community contributes to that renderer will be impactful.

---