Live data from Hacker News

Rio: Terminal app built over WebGPU, WebAssembly and Rust

github.com

41–50 of 134 posts

Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust

#41

What's the implication of using WebGPU? Better terminals in the browser? Better electron terminals? A quirk for better native portability?

VSCode's terminal is rendered with WebGL (a cousin of WebGPU), since VSCode is an Electron app

Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust

#42

My 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

Yeah I'd love to know what this is aiming for over WezTerm, which already supports both WebGPU and OpenGL rendering. Maybe just that it is closer to being able to run in a browser?

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

#44
post #30

I 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.

I think the reasons are often good: https://lobste.rs/s/fikvmn/farewell_macos#c_swz7p7

Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust

#46
post #30

I 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.

I've tried a gazillion terminals but I always come back to the built-in Terminal.app. I appreciate that it has no bugs (that I know of).

Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust

#47
As 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?

Also, which terminal emulator would you recommend?

Re: Rio: Terminal app built over WebGPU, WebAssembly and Rust

#48
Sometimes "now with added GPU" is not the issue at all.

There'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

#49
post #30

I 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.

With iTerm.app, getting a message that "your system ran out of application memory" is a reason for me to stick to the Terminal.app.

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

#50

As 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…

Some older terminals are slow enough to rate limit text output from things like streaming logs. I don't think that's specifically a GPU versus CPU, though.

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.

Post reply on HN