Skip to content

Optimized performance for low-bit-rate terminals. #199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

yesthatjwz
Copy link

Performance was poor on actual physical terminals running at low bit rates, e.g. 1200 baud, because it was repainting the whole screen each time, and being wasteful with cursor motion. This patch adds several optimizations to speed it up significantly:

  • Only write a character when it has changed.
  • Only alter attributes when they have changed.
  • Write rows first rather than columns first so that we can move to the right with a single SPC byte instead of a full cursor-motion command like "\e[24;80H".

With this patch, number of bytes written has probably been reduced by around 80%, maybe more.

Thanks!

}
if (matrix[i][j].val == -1) {
addch(' ');
} else if (lambda && matrix[i][j].val != ' ') {
addstr("λ");
} else if (matrix[i][j].val < 0xFF) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be < 0x7f instead? That's where UTF-8 goes multibyte. I think this will mis-display characters in the Latin-1 block.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are 32 bit Unicode characters, not multi-byte UTF-8 sequences.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"These" are indeed wchar_t but addch says vaguely it expects a "character" (but takes a single byte) and so it's not clear to me whether we can write ¶ the pilcrow or similar which are outside ASCII though fit in a single byte. If the terminal speaks UTF-8 (as a modern terminal probably does) then there needs to be 2 bytes emitted by the curses implementation to make that symbol.

I tried to see what happens here and discovered that I'm sufficiently rusty that I wasn't able to write a working test (the painkillers and/or broken left hand may not have helped but eh) but if it does work to emit addch a value like 0xB4 on an UTF-8 terminal that probably deserves a comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants