|
| ▲ | javcasas 4 hours ago | parent | next [-] |
| > For each frame our pipeline constructs a scene graph with React then > -> layouts elements > -> rasterizes them to a 2d screen > -> diffs that against the previous screen > -> finally uses the diff to generate ANSI sequences to draw Yup. Overengineering. |
| |
| ▲ | AceJohnny2 3 hours ago | parent | next [-] | | This is a decades-old design pattern when CPU >> IO. Emacs has been doing just that since the 80s, when people were complaining about "Eight Megs And Constantly Swapping". See "redisplay" [1] This minimizes screen flash. You can't rely on terminals doing double-buffering. [1] https://github.com/emacs-mirror/emacs/blob/c29071587c64efb30... or a more user-friendly overview, Daniel Colascione's seminal "Buttery Smooth Emacs", snapshotted at e.g. https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7... | | |
| ▲ | strix_varius 7 minutes ago | parent [-] | | lol what? There are definitely ways to make non flashing terminal UIs without this total insanity. |
| |
| ▲ | Melatonic 4 hours ago | parent | prev | next [-] | | It's like the Citrix of AI :-D | | | |
| ▲ | Aperocky 3 hours ago | parent | prev | next [-] | | It's product bloat. It's not recognizing that they are just one building block that should do one thing well, like tmux. You don't need a computer display on your fridge for the same reason, but Anthropic think you do. You should see virtual ice getting created and they should correspond to the actual ice behind the door - think of how amazing that is! And it's not even completely a bad idea. make it claude-code-react-beauty of some way to take it off, it would be far more palatable. | | |
| ▲ | mapBasketWand 2 hours ago | parent [-] | | I love the idea of installing high resolution cameras in the fridge to monitor the ice maker to feed into a vision model that renders digital ice to the exact position of the real ice on the fridge’s giant screen | | |
| |
| ▲ | megous an hour ago | parent | prev | next [-] | | React part maybe. The rest is what any TUI that's using ncurses would do. :) It really bothers me that most of the TUI harnesses are using 100% CPU quite a lot just printing stuff to terminal. Seems ridiculous. I guess it comes from syntax highlighting/formatting, which is probably not done incrementally, but over the entire so far displayed block of output, recomputed from the beginning for each new streamed in character. Can't imagine anything else causing the rendering to gradually grind to halt when eg. thinking block is open in opnecode and updates get palpably slow as it grows. Terminal output itself is fast and consumes almost nothing. You can have 60fps terminal apps that update content every frame and that consume almost no CPU time. | |
| ▲ | Animats 4 hours ago | parent | prev | next [-] | | What is "frame" in this context? Video frame, or something else? | | |
| ▲ | javcasas 4 hours ago | parent | next [-] | | > -> rasterizes them to a 2d screen > We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written. It looks like video frame, full framebuffer, generated and parsed at 60fps. It surprises me they haven't introduced GPU shaders, 16x oversampling and raytracing. Maybe for next release. | |
| ▲ | layer8 4 hours ago | parent | prev [-] | | The contents of the terminal screen at any given point in time. |
| |
| ▲ | abletonlive 3 hours ago | parent | prev [-] | | Care to explain how you'd engineer it instead? | | |
| ▲ | hungryhobbit 2 hours ago | parent | next [-] | | Why would anyone ever do that? Make Claude do it! | |
| ▲ | mudkipdev 16 minutes ago | parent | prev | next [-] | | A reminder that anthropic has great rust/go sdks that they could have written their own tui in. | |
| ▲ | stevenhuang an hour ago | parent | prev [-] | | Not use react native for a cli app for one, lol. Ratatouille rust cli lib will be a good start. |
|
|
|
| ▲ | munificent 4 hours ago | parent | prev | next [-] |
| As someone who maintains a roguelike with a terminal-like UI that: 1. Maintains an internal representation of what the game thinks is on screen. 2. Runs the game for one frame which updates that representation. 3. Generates a diff to see how that differs from what's actually on screen. 4. Executes the minimum set of draw calls to get the screen to match the internal representation. It's really not that hard. It's a few hundred lines of code. |
| |
| ▲ | javcasas 4 hours ago | parent [-] | | Sure. For a videogame. > -> rasterizes them to a 2d screen Also you forgot "render to a framebuffer, then parse the framebuffer back to chars". Anyway, I'm off to construct the new `ls` command. It will render the list of files to a mesh of billions of polygons in a GPU with advanced shaders, 16x oversampling, HDR and all the graphic acronyms I don't understand, then read the resulting image, find the nearest character in the ANSI charset and use that one. It will be _glorious_ (and profoundly stupid) | | |
| ▲ | ux266478 3 hours ago | parent | next [-] | | Could be improved. Encode the image to webp with high compression settings and handle the ASCII mapping by spinning up a local LLM to do OCR on it. Individually. For each cell. | |
| ▲ | tikimcfee 2 hours ago | parent | prev [-] | | lol... I know you meant this comically, but you just called me out and it's glorious: https://glyph3d.dev I built a truly glyph based instanced quad system to render millions of characters in space at once. |
|
|
|
| ▲ | applfanboysbgon 4 hours ago | parent | prev | next [-] |
| I hadn't seen that quote before, what an embarrassing thing to go on the internet and write... |
|
| ▲ | replwoacause 4 hours ago | parent | prev | next [-] |
| Why the hell does it need to be so complex? People have been making TUIs for decades. Did we need a small game engine to run claude code? |
| |
| ▲ | imjonse 4 hours ago | parent | next [-] | | They forgot to add 'make it as simple as possible' in the prompt is one possible cause. On a more serious note using a react-like lib for TUI in the hope you'll share the codebase with the web version is a more likely explanation. Still not the best idea. | | |
| ▲ | javcasas 4 hours ago | parent [-] | | React is not that stupid to re-render in a loop at 60fps and instead waits for changes to happen before re-rendering. It even batches changes and stuff. | | |
| ▲ | the_gipsy 12 minutes ago | parent [-] | | You don't need React for reactive TUIs - at all. I can understand chosing React for web, but for a TUI it sounds like a really poor idea. And in practice we can see that the claude code TUI is also poor. |
|
| |
| ▲ | comex 2 hours ago | parent | prev | next [-] | | It doesn’t need to be that complex, but it can be that complex without being slow. Claude Code’s interface is extremely simple. It has tons and tons of headroom to tack on performance overhead without it being noticeable at all. You just have to not do dumb things like redraw the entire UI every time a spinner spins. | | |
| ▲ | hungryhobbit 2 hours ago | parent | next [-] | | "We made our app chew up so many unnecessary resources that we can use even more resources in the future, and no one will notice" is not the strongest engineering idea I've ever heard. | |
| ▲ | grogers an hour ago | parent | prev [-] | | It may not be slow, but this crazy complexity is probably a hint at why it can't even scroll up without jumping to the beginning of time. |
| |
| ▲ | Quekid5 4 hours ago | parent | prev | next [-] | | Must have 120 fps for answers arriving in [buffering] 30 seconds. | |
| ▲ | wyre 3 hours ago | parent | prev [-] | | I can't help but think it's their engineer's and PM's making these decisions, since I know that if you asked Claude to write a TUI there is no world it would recommend whatever the frontend architecture of claude code is. |
|
|
| ▲ | qwery 3 hours ago | parent | prev | next [-] |
| ~ "it's not a TUI! <describes an outrageously overengineered TUI> and my dad works at Nintendo" curses, bud. curses. It's genuinely difficult to tell how much of this is true. The post is obviously 100% posturing, but some of the words describe things that could be done. Very few game engines do anything I'd describe as rasterisation. That's kind of the point of a GPU. Well, it used to be.
I suppose "small game engines" might be more likely on average to include a rasteriser. The typical reason for this is because the author wanted to write it.
Whereas big engine make triangle give hardware go brrr. So I assume here 'rasterize' means 'printf'.
And diffing screens means diffing 50..150 lines of text.
And "generating ANSI sequences to draw" means 'printf' with some ANSI sequences interpolated in. Then there's the frame budget. You have to understand they are operating within a strict frame budget -- they're not messing around, OK. They have a 16 ms frame budget, so they burned 11 ms and now have a (roughly) ~5 ms approx. budget for the final 'printf' in the chain??? |
|
| ▲ | layer8 4 hours ago | parent | prev | next [-] |
| > For each frame our pipeline constructs a scene graph with React then
-> layouts elements
-> rasterizes them to a 2d screen
-> diffs that against the previous screen
-> finally uses the diff to generate ANSI sequences to draw That’s rather sickening. |
| |
| ▲ | Fr0styMatt88 4 hours ago | parent | next [-] | | So I’m wondering what ‘rasterizing’ literally means in this case. I imagine it’s just creating a 2D map of elements at a very low (probably character) resolution, then diffing that against the last generated map to come up with an optimal ANSI sequence to send to the terminal, would that be right? Seems like a cool puzzle to solve. I wonder what the engineering and organisation tradeoffs were that lead to it — does it let them reuse a bunch of existing code? I wrote a TUI library back in the day for Turbo Pascal — it was essentially taking an immediate-mode approach (which in this context is just a fancy way of saying it was procedural haha). | | |
| ▲ | fluoridation 3 hours ago | parent [-] | | "Rasterizing" means just one thing in this context: to transform a data structure into an array of pixels. It seems absurd to do this, given that the next step must be to convert back from pixels to text data, but maybe they have some way to generate predictable sequences of pixels (e.g. the character "t" is always rendered as the same pattern of pixels), such that they're cheap to convert back. If they're doing anything else, the word "rasterizing" is being misused. |
| |
| ▲ | 4 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | dom96 2 hours ago | parent | prev | next [-] |
| > https://fxtwitter.com What is this? |
| |
| ▲ | nemomarx 38 minutes ago | parent [-] | | Proxy that makes Twitter links embed on discord, for whatever reason. Something about api access without accounts I assume |
|
|
| ▲ | orliesaurus 2 hours ago | parent | prev | next [-] |
| when they announced /pet mode or whatever - that was really the end of the line for me. |
|
| ▲ | agumonkey 3 hours ago | parent | prev | next [-] |
| this allows for comfortable ergonomics IMO not that it could be leaner for sure but i get the reasoning behind the tui rendering layer |
|
| ▲ | pragmatic 4 hours ago | parent | prev | next [-] |
| Somebody read/watched too much Casey Muratori. |
| |
|
| ▲ | PunchyHamster 3 hours ago | parent | prev | next [-] |
| Well it runs on something they didn't design (Electron) using GUI library they didn't design (React) For company with that much AI you'd think if it was actually good, doing that part in fast and performant way would be "easy" |
| |
|
| ▲ | overgard 3 hours ago | parent | prev | next [-] |
| And yet, nobody that writes game engines would do it this way because game engines need to be efficient.. |
|
| ▲ | 0xbadcafebee 3 hours ago | parent | prev [-] |
| If they used an actual game engine to render a 3D UI from scratch it would be more efficient |
