(no title)
bcherny | 18 days ago
That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.
bcherny | 18 days ago
That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.
wild_egg|17 days ago
Write the full content to a file and have less display it. That's a single "render" you do once and write to a file.
Your TUI code spawns `less <file>` and waits. Zero rendering loop overhead, zero tearing, zero stutter. `less` is a 40-year-old tool that exists precisely to solve this problem efficiently.
If you need to stream new content in as the session progresses, write it to the file in the background and the user can use `less +F` (follow mode, like tail -f) to watch updates.
extr|18 days ago
o7
snovv_crash|17 days ago
bombela|18 days ago
Heck, simply handle the scrolling yourself a la tmux/screen and only update the output at most every 4ms?
It's so trivial, can't you ask your fancy LLM to do it for you? Or you guys lost the plot at his point and forgot the most basics of writing non pessimized code.
troupo|17 days ago
They did. And the result was a React render loop that takes 16ms to output a hundred characters to screen and tells them it will take a year to rewrite: https://x.com/trq212/status/2014051501786931427
SPICLK2|17 days ago
The real problem is their ridiculous "React rendering in the terminal" UI.
troupo|17 days ago
Only if you use React as your terminal renderer. You're not rendering 10k objects on screen in a few milliseconds. You're outputting at best a few thousand characters. Even the slowest terminal renderer is capable of doing that.
bethekidyouwant|18 days ago
SPICLK2|17 days ago