11 ms·
Rio: Terminal app built over WebGPU, WebAssembly and Rust
- osener 3y agoThis 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?
- dagurp 3y agoIt's only available on mac
- pastacacioepepe 3y agoCheck the roadmap, it's macOS desktop -> web browser -> linux desktop -> windows desktop -> nintendo switch (??)
- WirelessGigabit 3y agoI'll switch when it runs on my Tamagochi.
- benadam11 3y agohttps://github.com/raphamorim/rio/blob/6443ebc7dda27041cb85e8e8d00d40924fa41e32/README.md?plain=1#L20 https://github.com/raphamorim/rio/blob/6443ebc7dda27041cb85e...
- norman784 3y agoAFAIK wezterm[1] and warp[2] are built on top of the WebGPU [1] https://wezfurlong.org/wezterm/ https://wezfurlong.org/wezterm/ [2] https://www.warp.dev https://www.warp.dev
- osener 3y agoI thought Warp was built with GPUI from https://zed.dev/ https://zed.dev/, which is built using Metal (thus macOS only). edit: found the reference at https://twitter.com/nathansobo/status/1619398212712022017 https://twitter.com/nathansobo/status/1619398212712022017
- norman784 3y agoThanks for the clarification.
- dizhn 3y agowezterm added support for it but that's not the only option. I don't really know much about webgpu but as far as I know wezterm does not run on the browser. https://wezfurlong.org/wezterm/config/lua/config/front_end.html https://wezfurlong.org/wezterm/config/lua/config/front_end.h...
- tambourine_man 3y agoFlutter uses canvas, AFAIK. Similar concept, but 2D
- deleted 3y ago[deleted]
- stickyricky 3y agoWhat's the implication of using WebGPU? Better terminals in the browser? Better electron terminals? A quirk for better native portability?
- vlakreeh 3y agoProbably portability, it's a pretty good low (but not too low) abstraction layer over the systems preferred graphics API. I'm not a graphics programmer but my understanding is it's closer to vulkan or metal in terms of control over the hardware compared to OpenGL, which has rocky support on Mac now anyways.
- Narishma 3y agoIt's not a clear win though. You gain some portability and lose some to platforms not supported by WebGPU.
- baudaux 3y agoI suppose it is just a question of time
- littlestymaar 3y agoWhat platform do you have in mind (given that WebGPU has at least 2 OpenGL backend, including one that supports WebGL)
- baudaux 3y agoMaybe building better virtual environments inside the browser
- brundolf 3y agoVSCode's terminal is rendered with WebGL (a cousin of WebGPU), since VSCode is an Electron app
- fyrn_ 3y ago
- graypegg 3y agoCool! Porting to the web is an interesting idea. I can’t help but imagine going back to the 70s and trying to show someone that yes, everyone has this full colour, mouse-supporting, GUI app platform accessible on any device and interlinked between billions of similar interactive documents from around the world… but it was really important that we set up a TTY. The smug (or horrified) look on their face would be priceless.
- deleted 3y ago[deleted]
- norman784 3y agoMy 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
- HeckFeck 3y ago- st, the most terminal we could fit into 3000 LOC
- ilrwbwrkhv 3y agoKitty has the lowest latency and is the best terminal in the market, but they are not on windows.
- manaskarekar 3y agoKitty is my favorite but acts weird when ssh-ing into other machines for reasons discussed on their github. (To do with setting the $TERM correctly)
- happens 3y agoHad 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
- JdeBP 3y agoKitty 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-kitty 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 then face "But my terminfo on that Linux distribution DVD that I got isn't up to date!", or "But my termcap on FreeBSD isn't up to date!". The answer to that problem is to point out that terminfo supports a local ~/.terminfo/ if one needs one, and FreeBSD termcap has a TERMPATH environment variable that one can point at a ~/.termcap.db file, or indeed one placed anywhere else, if the system termcap database isn't up to date.
- flashback2199 3y ago[flagged]
- danstewart_ 3y ago> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- flashback2199 3y agoThanks, I have edited my comment to meet the requirements of the community.
- deleted 3y ago[deleted]
- v3ss0n 3y agoYeah I still can't understand the point of requiring GPU for terminals. What webgpu needed is graphics drawing applications are most graphics drawing apps on web are still using canvas 2d or SVG, not even webgl. If we are to build a graphic heavy tool like figma - all choices we have are mostly SVG.
- Tade0 3y agoRendering text is surprisingly resource-intensive. 10 years ago I was tasked with making a mobile browser game and the thing that took 30% of the time when rendering a frame were the few bits of text that were there to display the score etc. Once we started heavily caching text, performance increased considerably.
- flashback2199 3y agoIsn'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?
- garganzol 3y agoThere are screenshots, but not a real thing to try (in browser). This is somewhat discouraging.
- maxmcd 3y agoAnyone see how to run it in browser? Would love to try that out. edit: seems like most of the wasm stuff is some tests within this lib: https://github.com/raphamorim/rio/tree/main/sugarloaf https://github.com/raphamorim/rio/tree/main/sugarloaf
- JdeBP 3y agoI 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 old syscons FreeBSD kernel built-in terminal emulator at https://tty0.social/@JdeBP/110424206935120790 https://tty0.social/@JdeBP/110424206935120790 for what I mean by really badly. It still does understand the control sequences, though.
- wvenable 3y ago256 colors ought to be enough for anybody.
- fnordpiglet 3y agoThat’s like 254 too many.
- CSSer 3y agoSounds like writing code in notepad.
- fnordpiglet 3y agoSounds like terminals as they existed for most of the life of computing. Honestly I’ve never found color added that much to my experience with a terminal and often ended up with poor contrast for certain things and a bunch of time tweaking color palettes. Since eMacs and vi has been two color for a lot of its life, I’d say it’s more like writing code with pretty bog standard code editing tools.
- tambourine_man 3y agoApple 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.
- JaggerJo 3y agoBut.. why? Couldn't you just use Rust + OpenGL/SDL2/.. or even AppKit if macOS is the only supported OS?
- awestroke 3y agoFeel free to use those things
- eschaton 3y agoYeah, it’s yet another webshit forcing things into their preferred tech stack no matter whether it meets the needs of the problem domain or even whether the tech stack itself is sensible. JavaScript doesn’t belong anywhere in anyone’s tech stack, and unless you’re making a web page neither do HTML or CSS.
- xcdzvyn 3y ago> JavaScript doesn’t belong anywhere in anyone’s tech stack, and unless you’re making a web page neither do HTML or CSS. Rio uses none of these things?
- th0ma5 3y agoIt always seems like this kind of thing will suffer from accessibility issues?
- deleted 3y ago[deleted]
- KrugerDunnings 3y agoI'd love some sixel support to embedded graphics in the terminal
- MayeulC 3y agoOr some terminal graphics protocol, which is more efficient than sixels: https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/
- KrugerDunnings 3y agoThat be fine also. I've been playing around with sixel and it's a great way to add plotting to a repl.
- doodlesdev 3y agoAs 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?
- NegativeK 3y agoSome 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.
- jacobsenscott 3y agoI think it is a little like when people trick out their honda civic with led lights, and new speakers, etc. It is fun, but you can get to all the same places just as well with a stock honda civic. IOW it seems there are a subset of hackers that are sort of terminal hobbyists.
- atomicUpdate 3y agoI use Terminator. I like all of the configuration that's possible with the layouts that can be done, plus it has right-click to paste, which I got used to with PuTTy. The default Terminal in Debian is very bare-bones by comparison.
- rShergold 3y agoIt may have something to do with this mind blowing exchange between Casey Muratori (a highly experienced game engine developer) and the Microsoft Terminal team. https://github.com/microsoft/terminal/issues/10362 https://github.com/microsoft/terminal/issues/10362 It really highlighted how crappy software gets written in large corporations. They told him rendering monospaced fonts on the GPU would involve a multi year PHD research project. Apparently they then went on to infiltrate his discord server so they could ask questions. Then write up a blog post calling the change "trivial". https://twitter.com/cmuratori/status/1522471966929653761 https://twitter.com/cmuratori/status/1522471966929653761
- JdeBP 3y agoSometimes "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.
- awestroke 3y agoJust use a non-graphical ssh session if you just want a shell on the remote machine
- MayeulC 3y agoDid you try ssh compression to see if it made any difference?
- JdeBP 3y agoNo. But it was like for like. It was the one single SSH connection in both cases, simply running cacademo with and without a DISPLAY environment variable. I think that part of the problem lies with SSH: the lack of batching as I mentioned, which might also be at ncurses' door too. Of course one wants terminal output to go over the wire as soon as possible, and not wait "until we have a buffer-ful". But not in this case. Rather, batching up the control sequences to change colour, cursor position, and then output the relevant character into a single exchange over the wire would be better. That would be equivalent to a an X primitive to write character X at position Y with attributes Z, which presumably goes as a single message over the wire. But a combination of whatever output buffering ncurses and libcaca are doing, what happens in the pseudo-terminal and sshd at the remote end, and then what happens at the local end when ssh is outputting to its pseudo-terminal, are all almost certainly strongly militating against that. ... In addition to converting lots of numbers from machine-readable to human-readable, then back to machine-readable again. (-: I should mention that at one point I was transcoding from AIXTerm to ITU T.416 colour control sequences. The latter are about 4 times as long as the former, and that noticeably slowed things down even further. Yes, I'm in favour of 24-bit colour like the other terminal emulator authors, but it does come at a measurable price.
- mteam88 3y agoI would love it if I could run this in the browser over SSH to a remote server... Is that possible?
- zamnos 3y agoMaybe Xpra would work?
- mteam88 3y agoXpra doesn't have a browser client as far as I can tell
- VikingCoder 3y agoThere are things like it for sure: https://tailscale.com/blog/ssh-console/ https://tailscale.com/blog/ssh-console/ https://twitter.com/bradfitz/status/1585678043515084800?lang=en https://twitter.com/bradfitz/status/1585678043515084800?lang... https://leaningtech.com/webvm-virtual-machine-with-networking-via-tailscale/ https://leaningtech.com/webvm-virtual-machine-with-networkin...
- mteam88 3y agoI know, I was thinking specifically for this project.
- gnabgib 3y agoNot presently - browsers prevent access to ports like SMTP, telnet, SSH[0]. Which you definitely want by default - you don't want a random website to be able to access services like that from your machine. [0]: https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?view=markup#l68 https://src.chromium.org/viewvc/chrome/trunk/src/net/base/ne...
- eatonphil 3y agoHow does one get full CJK Input Method Editing working for a project like this? I've sort of been looking into it and it doesn't seem there are cross platform libraries for handling IMEs and not many people talk about even the platform-specific APIs.
- VikingCoder 3y agoI hope it gets modules to make it look as awesome as Cool Retro Term: https://github.com/Swordfish90/cool-retro-term https://github.com/Swordfish90/cool-retro-term
- pdimitar 3y agoKinda off-topic: what's the fastest terminal for macOS these days?
- graypegg 3y agoNothing to back this up, but alacrity?
- jackbravo 3y agoin 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.
- pdimitar 3y agoYeah I am using it already. But recently I saw a thread here on HN that measured terminals by other means than what Alacritty advertises... and it was actually one of the slowest. Hence I got slightly curious but not enough to pursue deeply.
- gkfasdfasdf 3y agoLooking forward to trying the web version on a chromebook and comparing to hterm.
- syrusakbary 3y agoI can't wait to have the terminal fully compiling to WebAssembly and runnable in Wasmer! [1] [2] [1]: https://wasmer.io/ https://wasmer.io/ [2]: https://github.com/raphamorim/rio/issues/25 https://github.com/raphamorim/rio/issues/25