What's the implication of using WebGPU? Better terminals in the browser? Better electron terminals? A quirk for better native portability?
Rio: Terminal app built over WebGPU, WebAssembly and Rust
41–50 of 134 posts
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#42My question is what's their selling point, I used the past few years few terminals that have pretty good features: - Alacritty minimal and blazingly fast - Wezterm with batteries included - Warp even batteries included
I have to take a moment to just evangelize WezTerm a bit. I switched over from iTerm in the last few months and IMO WezTerm's absolute killer feature is its Lua-based configuration. You can do so much with it, down to running scripts on key binds, and the API is powerful enough to do virtually anything you want. For example I have some key binds that act differently when the active pane is running emacs vs. a shell.
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#43It always seems like this kind of thing will suffer from accessibility issues?
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#44I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-: There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly , and some do, almost everyone tries to support this colour system now. See the screenshot of the…
Apple didn’t get the memo it seems. Terminal.app has been unchanged in many, many years. I still stubbornly use it as my daily driver for some probably terrible reason.
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#45This is the first GUI app I've seen built with WebGPU. This is pretty interesting, could this be the future of cross platform GUI frameworks?
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#46I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-: There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly , and some do, almost everyone tries to support this colour system now. See the screenshot of the…
Apple didn’t get the memo it seems. Terminal.app has been unchanged in many, many years. I still stubbornly use it as my daily driver for some probably terrible reason.
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#47Also, which terminal emulator would you recommend?
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#48There's a demo program that comes with libcaca, called cacademo. It can either output text to standard output with ECMA-48 control sequences, or crank up a built-in X client that displays a very simple text window.
I SSHed into a remote machine with it from a local machine that had an X server. Tunnelled over the SSH connection, the X version of the demo was a little slower than running directly on the remote machine's own display, but mostly didn't drop frames. The mode where it sent ECMA-48 control sequences over the SSH connection to a local terminal emulator was woefully slower, to the point that it was displaying less than 1 frame a second sometimes, and visibly tearing the display. I tried it with both Microsoft Terminal and MobaXTerm to see whether it was the terminal emulator. It wasn't.
Sending colour information as ITU-T T.416 RGB control sequences, or even as AIXTerm 16-colour control sequences, to be interpreted by a control sequence state machine in the terminal emulator and turned into a display buffer and graphics drawing commands, turns out not to be as efficient over SSH as the X protocol over SSH. Yes, X11.
The X path was going through an X client library to the X server. It was probably using the old X11 primitives for text, rather than doing client-end rendering. The terminal emulator path was going through ncurses, then probably wasn't being batched up very much over the SSH connection, and then was going through a decoder that had to (amongst other things) parse numbers from human-readable to machine-readable thousands of times per frame because ECMA-48 uses decimal-character-encoded values in control sequences, and the cacademo program outputs lots of colour changes, frequently a colour change for each successive cell.
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#49I have news for whoever did that screen shot: 256 colours is not "all colours" nowadays. (-: There was a real push, which must be approaching a decade ago at this point, to get all terminal emulators able to understand the ITU-T T.416 control sequences for direct 24-bit RGB colour. Even if they implement it really badly , and some do, almost everyone tries to support this colour system now. See the screenshot of the…
Apple didn’t get the memo it seems. Terminal.app has been unchanged in many, many years. I still stubbornly use it as my daily driver for some probably terrible reason.
It's a 96 GiB of RAM machine, for chrissake! That ought to be enough for everybody!
Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust
#50As someone who still just uses whatever terminal emulator my desktop environment provides, what are the advantages of choosing another terminal emulator application? Also, what's the point of providing GPU rendering on the terminal? I've never experienced latency or any problems otherwise related to rendering, so I wonder why some terminals nowadays pride themselves in using GPU rendering. Am I missing something? Als…
I use Terminology, from the Enlightenment WM team. It's fast, supports unicode, is easily configurable, and behaves how I, personally, prefer. But if you don't really have a preference, I don't think fancy different terminals are going to be that important.