In the 1980s, full-screen TUI programs did significant work to optimize terminal output. A complete redraw of an 80 by 24 screen at 300 BPS was not quick. So applications normally only wrote changes to the screen, only performing a full redraw when requested by a Control-L input (or some such).
Terminals have sped up, but the amount of terminal I/O to draw a screen has increased, too. Nowadays there are lengthy SGR 38/48 sequences for 24-bit RGB, plus the other SGR sequences for attributes, plus of course characters that are now commonly multi-byte UTF-8 encodings, including box drawing characters.
So the old considerations of optimizing terminal output still apply nowadays to full-screen TUI applications. Optimize out cursor motions that move to where the cursor currently is; replace absolute motions to nearby positions by shorter relative motion control sequences; optimize out superfluous attribute and colour changes; replace onwards horizontal cursor motions by just rewriting the relevant characters; skip unchanged cells; and so forth.
When it is a Win32 application, it uses console I/O and this does not matter quite as much, although it's still a waste of system call context switches to overwrite a console screen buffer with what is already there. But when it is using terminal I/O this matters significantly.
The Rust terminal handling is actually fairly poor overall. This list, for example, is in reality a lot longer. The terminfo database records a lot more terminal types that understand these escape sequences. "putty" for one egregiously missing example.
Personally, rather than treat lack of capability as the norm with a paltry list of exceptions, I prefer the opposite assumption that (except for "dumb") the world has nowadays reached 1976 capability levels. (-:
Terminals have sped up, but the amount of terminal I/O to draw a screen has increased, too. Nowadays there are lengthy SGR 38/48 sequences for 24-bit RGB, plus the other SGR sequences for attributes, plus of course characters that are now commonly multi-byte UTF-8 encodings, including box drawing characters.
So the old considerations of optimizing terminal output still apply nowadays to full-screen TUI applications. Optimize out cursor motions that move to where the cursor currently is; replace absolute motions to nearby positions by shorter relative motion control sequences; optimize out superfluous attribute and colour changes; replace onwards horizontal cursor motions by just rewriting the relevant characters; skip unchanged cells; and so forth.
* https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47...
The Rust full-screen TUI code in Broot (and common Rust libraries) does not do any of this.
* https://github.com/Canop/broot/blob/d8ba179946ad10d777f93b4a...
* https://github.com/crossterm-rs/crossterm/blob/41ff73e3d3763...
When it is a Win32 application, it uses console I/O and this does not matter quite as much, although it's still a waste of system call context switches to overwrite a console screen buffer with what is already there. But when it is using terminal I/O this matters significantly.
The Rust terminal handling is actually fairly poor overall. This list, for example, is in reality a lot longer. The terminfo database records a lot more terminal types that understand these escape sequences. "putty" for one egregiously missing example.
* https://github.com/crossterm-rs/crossterm/blob/41ff73e3d3763...
* https://invisible-island.net/ncurses/terminfo.ti.html#tic-pu...
Personally, rather than treat lack of capability as the norm with a paltry list of exceptions, I prefer the opposite assumption that (except for "dumb") the world has nowadays reached 1976 capability levels. (-:
* https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47...