Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rio: Terminal app built over WebGPU, WebAssembly and Rust

github.com

Post reply on HN
Print view View original

91–100 of 134 posts

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

#91

Post by [deleted] »

tambourine_man wrote: post #40
JdeBP wrote: 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.

[deleted]

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

#93

Post by timcavel »

tambourine_man wrote: post #40
JdeBP wrote: 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.

[dead]

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

#94

Post by moonchrome »

doodlesdev wrote: post #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? Als…

You never seen a case where a slow terminal would throttle the app running because it couldn't render output fast enough ?

I use JetBrains IDEs and honestly their built in terminal emulators are embarrassingly slow. VSCode is buttery smooth in comparison. Sad state of things.

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

#95

Post by WesolyKubeczek »

0x457 wrote: post #58
michaelmcdonald wrote: post #51

Earlier quoted context omitted.

How on earth have you had iTerm use up so much memory it's given you an error? I've been using iTerm for years on some absolute crap machines, abusing iTerm with tmux and numerous customizations, and have never received that error.

Unlimited scroll buffer + compiling something large with verbose logs non-stop?

Unlimited scroll buffer, but good scrollback hygiene (I clear scrollback after I don't need it), and it ran out of memory by just sitting there — I was using something else during that time and all terminals had been at the shell prompts.

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

#96

Post by nxpnsv »

sjm wrote: post #42
norman784 wrote: post #9

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

I love how WezTerm feels consistent between my Linux and Mac machines. Lua config took me a while to figure out, but keeping it simple works well...

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

#97

Post by jackbravo »

graypegg wrote: post #88
pdimitar wrote: post #85

Kinda off-topic: what's the fastest terminal for macOS these days?

Nothing to back this up, but alacrity?

in their README:

> Is it really the fastest terminal emulator?

Benchmarking terminal emulators is complicated. Alacritty uses vtebench to quantify terminal emulator throughput and manages to consistently score better than the competition using it. If you have found an example where this is not the case, please report a bug.

Other aspects like latency or framerate and frame consistency are more difficult to quantify. Some terminal emulators also intentionally slow down to save resources, which might be preferred by some users.

If you have doubts about Alacritty's performance or usability, the best way to quantify terminal emulators is always to test them with your specific usecases.

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

#98

Post by jackbravo »

tambourine_man wrote: post #40
JdeBP wrote: 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 love that Terminal.app, out of the box, changes the colorcheme depending on your desktop dark or light configuration. iTerm does this on new versions, but only on 10.14 and later, which my company doesn't support yet :-p

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

#99

Post by yakubin »

tambourine_man wrote: post #40
JdeBP wrote: 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 actually have the opposite problem. I’d like to limit terminal apps to just the 16 colours I have defined in my terminal settings (which is actually 3 colours in my case), but some apps (like the rust compiler e.g.) emit escape sequences which slightly change the shade in some places, in 256 colour space. I’d like to disable those 256 colours and limit everything to 16. I don’t think I can though.

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

#100

Post by happens »

JdeBP wrote: post #86
happens wrote: post #60

Earlier quoted context omitted.

Had that problem for a while too, but you can actually really easily set the TERM variable for every ssh connection separately from your local TERM. Just put the following in your ~/.ssh/config: Host * SetEnv TERM=xterm-256color

Kitty isn't "xterm-256color". That's something that Thomas Dickey, and I, and others, have pointed out time and again. It's just plain wrong to say to programs that something is XTerm when it isn't. Kitty is, unsurprisingly: https://invisible-island.net/ncurses/terminfo.src.html#tic-k... The problem that people have is different anyway. When they're doing things correctly, and setting the correct terminal type, they…

I'm not sure what to make of this. The terminfo you linked suggests to me that kitty provides at least the same capabilities as xterm-256color, unless I'm understanding the "use" capability wrong.

Most machines I've SSHed into didn't have kitty's terminfo installed, which results in many things not working. Using xterm-256color as a safe fallback has always worked for me however. It would always be possible to define the TERM variable per host and use TERM=kitty for hosts that have the correct terminfo installed. Is there a drawback to that apart from not being technically correct?

Post reply on HN