Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
> My initial attempt was based on placing character images, one-by-one, onto a canvas element, but it was horribly sluggish.
I've done web-based terminal-style renders in a number of different ways for my roguelike [1]. I've done both DOM and canvas renderers. I found that the fastest approach to be:
1. Render each glyph to a canvas.
2. Only re-render glyphs that actually changed.
Doing that was much faster than using the DOM. I imagine I could go even faster using WebGL but at this point, I considered the performance good enough.
[1]: http://munificent.github.io/hauberk/
One of my proudest moments during in the development of "Linux on the Web" had to be the creation of a Terminal application (try it at https://lotw.site/shell) that can render its output with near-native efficiency. My initial attempt was based on placing character images, one-by-one, onto a canvas element, but it was horribly sluggish. Then I started playing around with a "Virtual Dom" (React-like) approach, wherein I convert the underlying data structure into an html string, and then set the innerHTML property of a div element, for every time the screen has to be redrawn. (Source code: https://github.com/linuxontheweb/LOTW/blob/main/root/code/ap..., the relevant code is the "render" function starting on line 569, and the innerHTML is set on line 940).
I don't know how many years its been that I started working on the Terminal application, but it was only within the past week or so that I "bit the bullet" and figured out how to do finger pad/mouse wheel scrolling of the output buffer (See the 'main.onwheel' function in the source code for that little tidbit!). Since I required fine-grained control over the rendering process, I could not rely on the "naive" way of doing scrolling on the web (which is to simply let the browser take care of the entire process).
Funnily enough, I just happened to have ported D-Flat to macOS and Linux in the last couple of weeks. Check it out (w/screenshots): https://github.com/ghaerr/dflat. It uses a small TUI library that maps multi-byte ANSI/xterm arrow key and mouse wheel inputs into unicode private-use codes for internal processing by D-Flat. It also remaps all of the IBM PC code page 437 characters for unicode output, and converts the entire "PC-compatible" screen image including attributes into ANSI terminal output, thanks to some nice code from the Cosmopolitan Project.
Interesting other library - React for the terminal. Allows you to build the UIs using familiar web techniques and even has react dev tools!
https://github.com/vadimdemedes/ink
You don't really need new TUI framework, when you can extend existing real GUI framework to just work in console https://github.com/jinek/Consolonia
I finally found a decent source of information:
https://github.com/termstandard/colors
The most obvious case of missing support is macOS’s Terminal.app. Years ago I imagine you could theoretically at least query the colours by some side channel, but sandboxing will doubtless have prevented that. And maybe it does support the querying, which to my mind is the more important of the two pieces of functionality when it comes to accessibility.
If I read https://github.com/Textualize/rich/blob/33040731973d44cf6326... correctly, if you specify a truecolor it will downgrade with the following code path:
# Convert to standard from truecolor or 8-bit