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

61–70 of 134 posts

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

#61

Post by flashback2199 »

littlestymaar wrote: post #33
flashback2199 wrote: post #24

Earlier quoted context omitted.

Isn't rendering text inside a graphics framework and then saying that rendering text is surprisingly resource-intensive a bit like implementing an O(n log n) algorithm with nested for-loops and saying that the problem domain is surprisingly resource-intensive? Surely the thing that was causing text rendering to be resource-intensive was doing it inside a graphics framework?

Rendering text, is resource intensive. If you don't rotate or zoom, then most of the work can be cached (at least when using latin fonts with few ligatures) which make things appear to be fast, but if you tried to render text in real time without caching (because you're allowing rotation and zoom, and you can't cache everything) then you'd see how expensive it is.

Okay, sure, rendering text that meets modern expectations is resource-intensive.

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

#62

Post by josephd79 »

WesolyKubeczek wrote: post #49
tambourine_man wrote: post #40

Earlier quoted context omitted.

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!

I've never had that issue before, but I switched awhile back to wezterm.

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

#63

Post by brundolf »

fyrn_ wrote: post #53
brundolf wrote: post #41

Earlier quoted context omitted.

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

WebGL is not really related to WebGPU in any way. WebGL is almost a strict subset of Gles3, WebGPU is a completely different API, sharing on a few concepts. They're about as related as Java and JavaScript

They're different APIs, but they have similar goals and benefits: expose native-adjacent performance for GPU tasks in a highly cross-platform API supported by browsers and other host software. The original poster was asking "why [vs native graphics APIs]?", and I think the "why" is the same for both.

Also- VSCode is literally an example of a use-case where you might do this in WebGPU, they just didn't

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

#66

Post by awestroke »

JdeBP wrote: post #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 l…

Just use a non-graphical ssh session if you just want a shell on the remote machine

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

#67

Post by awestroke »

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?

Well just limit the scroll buffer then

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

#68

Post by awestroke »

natrys wrote: post #54
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

Meanwhile I have to wonder what's the selling point of these over good old urxvt? It has an ecosystem of perl plugins, which has all the batteries I need and more. In its daemon/client mode I can have 20+ terminal windows open and they consume sum total of like 30MB memory, with embedded perl interpreter and everything. I feel like one or two instances of these modern incarnations is enough to completely dwarf that n…

Well, if you search for these projects yourself and read the first few paragraphs on their websites, you might learn the selling points. Warp has a lot of features that are just not possible in urxvt.

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

#70

Post by norir »

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 switched to Terminal.app from iterm2 almost 10 years ago because of horrific scroll and input latency for iterm2 after one of the osx upgrades (maybe Mavericks or Yosemite?). For the last few years I've been using kitty, which works well and for my setup allows me to eschew tmux. But Terminal.app still mostly just gets the job done so if it's working for you, I'd say stick with it.
Post reply on HN