Hacker News Reader

Comment by layer8 | Hacker News Reader

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

View on HN

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

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

Yes, the much more plausible explanation is that the word rasterize was misused there. They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive.

> They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive

No one has ever done that. Even top[0], which does full screen refresh, clear the screen (if necessary) and write the new information (the period is in seconds, not ms). No need to diff. That would be like diffing a file, just to find which bytes to update.

[0]: https://cvsweb.openbsd.org/checkout/src/usr.bin/top/display....

I don't understand why you would make such a confident negative claim rather than ask for an example or otherwise engage in discussion. Particularly given that you replied to a comment elsewhere in this very thread that links to a real world example of exactly such an implementation! [0] See in particular this part of the source. [1]

I agree that most programs don't bother to do that but please recall that my claim was merely that what Claude Code is claimed to be doing with regards to diffing is a well established and long standing optimization. The important point being that it is neither expensive, novel, or particularly complex thus not an excuse for poor performance.

[0] https://news.ycombinator.com/item?id=48405259

[1] https://github.com/emacs-mirror/emacs/blob/c29071587c64efb30...

The emacs code is not purely diffing. They already have the final output, they’re mostly comparing it to see a cheaper way to update than render the output. I’m pretty sure the curses library have the same thing.

But ink, the library Claude is using, defines a tree data structure for the main concept. The diff there is about comparing the old tree and the new tree created by the update, and then updating the node that has changed. That means if a single character change inside a bing panel, the whole thing is rewritten. And if you have something that is updating a lot, that means flickering.

The diffing that ink does is just architecturally wrong. You can create a dom, but a dom is not a concept for the terminal. It’s up to you to optimize its rendering. But just diffing the dom structure like react does is not optimizing, it’s busywork.

Reply on news.ycombinator.com