Whose xterm is it anyway?
tedunangst.com
tedunangst.com
It makes a lot of sense. Much goes into your text rendering beyond what was necessary in your VT100. Every screen I see is anti-aliased, horizontally and vertically aligned, with 'lines' of text that can wrap or be colored or myriad other things according to the byzantine and arcane standards of the escape codes and ones that have come after. Re-drawing even a fairly large amount of text is fairly non-trivial cpu and gpu time. I found I got way better performance and less lag from my machine if I disabled the alpha transparency on my terminal windows. Processing power is very high, but still far from unlimited.
Why would I use that instead of rxvt ?
i=0;while true; do echo $i;i=$((i+1));done
(tyls is ls with thumbnails, and tycat is like cat except that if you try and cat a movie file to stdout it will display a video player instead of raw bytes)
Of course if you're in difference circumstances the answer changes. But there's no particular virtue in using a worse terminal so that more of your RAM sits there with lots of 0s in it.
Ever accidentally cated a 4TB disc? It's… fun.
Egad, that pulls in a lot of dependencies! But yeah, it's blazingly, impressively fast.
Check out st[1] sometime. It's not as fast as either terminology or rxvt, but it's fast enough.
I also highly recommend using urxvt[2], which not only has very fast rendering and support for a lot of modern features, it has a few settings you enable that specifically address the too-much-scrolling speed issue. From urxvt(1):
jumpScroll: boolean
[...] specify that jump scrolling should be used. When receiving
lots of lines, urxvt will only scroll once a whole screen height
of lines has been read, resulting in fewer updates while still
displaying every received line [...]
skipScroll: boolean
[...] specify that skip scrolling should be used. When receiving
lots of lines, urxvt will only scroll once in a while (around 60
times per second), resulting in far fewer updates. This can result
in urxvt not ever displaying some of the lines it receives [...]
...did you know that it supports rendering italics? Not particularly well, mind, especially with bitmap fonts, but it's there:
https://en.wikipedia.org/wiki/File:Codepage-437.png
The standard X terminal fonts ("fixed") are pretty good for other sizes, although I've fixed mine with a slashed zero:
ls -lR / in urxvt terminal window - 16 s
vs
ls -lR / in gnome-terminal window - 3m17s
ls was run several times to make sure all information was cached. Same font, same window size, etc.
But I find that rxvt is quite speedy (in both Linux and OpenBSD) not to cause any noticeable lag when using "pretty fonts". Unlike OS X, where both Terminal and iTerm are still frustratingly slow at rendering text. Sometimes I'll fire up a Linux VM just to have a fast terminal and nothing else.
(IMO, you're right about antialiasing, though)
If your terminal can't draw a screen of text at 60fps on a semi-modern computer, it has a very inefficient renderer.
So it's not just priority inversion that is a potential problem, but also non-obvious layers of abstraction.
Unfortunately that means you're stuck using a terminal with the most brain dead shortcut keys in the world. Invariably I sit down at a coworker's keyboard, hit alt-F, and instead of skipping forward a word, I open the File menu.
tonumber() is LuaJITs cast for pointers to integers. There are some arguments for it to stay.
I meant to refer to "tonumber(oldsize[0])" used to cast from a ctype size_t to a lua number (doubles) (I missed that's it's also used for casting pointers). Now I realise that this is needed because implicit casting from 64 bit ints to a double would reduce precision. It's just a very minor thing that "for" loop bounds must be lua numbers.
(For those who, like me few years ago, don't know what above does - it's writing directly into STDOUT of a process, which is available as a file descriptor 0 in /proc/[PID]/fd).
[1] https://github.com/holygeek/wmgr/blob/master/xterms.conf.pl....