Live data from Hacker News

XTerm: It's Better Than You Thought

aduros.com

31–40 of 159 posts

Re: XTerm: It's Better Than You Thought

#31
Further tips that might interest people:

Xterm should support sixels out of the box but needs further configuration to make it work properly:

    XTerm*decTerminalID: 340
    XTerm*numColorRegisters: 256
If you want to scroll the content in alternate screens like less instead of the scrollback buffer with your scroll-wheel you have to enable:

    XTerm*alternateScroll: true
If you want a subtle and less jarring visual terminal bell you can enable this option which flashes only the current line and not the whole screen:

    XTerm*visualBell: true
    XTerm*visualBellLine: true
    XTerm*visualBellDelay: 20

Re: XTerm: It's Better Than You Thought

#33

It's decent and supports direct-color and all the obscure features of xterm of course, that others don't like querying and setting the color palette. It doesn't support most(any?) of the bleeding-edge sequences for hyperlinks and underline styling. It may have better input latency than xfce, but what are you running it on, a 486? Maybe for RPi, but—it has poor paint performance as well. It will flash if you try to do…

> Things like tabs and a proper scrollbar are a minimum for me.

I use xterm in tmux, no need for native scrollbar or tabs.

Re: XTerm: It's Better Than You Thought

#34

Earlier quoted context omitted.

> Offloads rendering to the GPU I don't understand this - isn't all rendering on a typical macOS or Linux desktop done via the GPU?

I believe the software has to take advantage of the GPU. The `foot` terminal renders on the CPU instead of the GPU, but beats GPU-accelerated `alacritty` anyway due to other effiency hacks described on their Performance page: https://codeberg.org/dnkl/foot/wiki/Performance

Hmm I think it's more the case that an application has to go out of its way to not render on the GPU. High level frameworks' basic rendering operations are, of course, always GPU accelerated. They'd be crazy not to be! It looks like Foot is rendering using CPU by talking directly to the compositor.

Re: XTerm: It's Better Than You Thought

#35
xterm is sadly very slow (you see line by line re-draw in midnight commander and things like that) on glamor/GPU accelerated Xorg server on all my ARM devices. I switched to st (https://st.suckless.org/) on my ARM devices, and while it has less features, it doesn't have this performance issue.

I never figured why that is, other than it not being a CPU issue.

Re: XTerm: It's Better Than You Thought

#36
post #16
post #11

Earlier quoted context omitted.

Here’s a non-Medium version[1], since Medium is similarly but completely unrelatedly, a disaster. [1] http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

The original UNIXUX site is very clever, but if the guy who actually wrote it is linking to Medium instead, I’m not sure if we can overrule him.

No one is getting overruled, you now have one additional choice of links to click on for the same material, free of charge.

Re: XTerm: It's Better Than You Thought

#37

It's decent and supports direct-color and all the obscure features of xterm of course, that others don't like querying and setting the color palette. It doesn't support most(any?) of the bleeding-edge sequences for hyperlinks and underline styling. It may have better input latency than xfce, but what are you running it on, a 486? Maybe for RPi, but—it has poor paint performance as well. It will flash if you try to do…

> Things like tabs and a proper scrollbar are a minimum for me. I use xterm in tmux, no need for native scrollbar or tabs.

Do you mean the reverse? I'm using a number of applications, the terminal is but one. So, I find a consistent interface is desirable.

Re: XTerm: It's Better Than You Thought

#38
post #35

xterm is sadly very slow (you see line by line re-draw in midnight commander and things like that) on glamor/GPU accelerated Xorg server on all my ARM devices. I switched to st ( https://st.suckless.org/ ) on my ARM devices, and while it has less features, it doesn't have this performance issue. I never figured why that is, other than it not being a CPU issue.

I believe it is not buffering draws, although have never checked the source.

Edit: I found this at the arch wiki:

    Troubleshooting - Flickering on scroll
    
    Warning: Double buffering may cause non-bitmap fonts to render incorrectly.

    Rebuild xterm using ABS and include the --enable-double-buffer flag:

    ./configure --prefix=/usr \
         ...
         --with-utempter \
         --enable-double-buffer
Could be more friendly.

Re: XTerm: It's Better Than You Thought

#39
post #35

xterm is sadly very slow (you see line by line re-draw in midnight commander and things like that) on glamor/GPU accelerated Xorg server on all my ARM devices. I switched to st ( https://st.suckless.org/ ) on my ARM devices, and while it has less features, it doesn't have this performance issue. I never figured why that is, other than it not being a CPU issue.

I believe it is not buffering draws, although have never checked the source. Edit: I found this at the arch wiki: Troubleshooting - Flickering on scroll Warning: Double buffering may cause non-bitmap fonts to render incorrectly. Rebuild xterm using ABS and include the --enable-double-buffer flag: ./configure --prefix=/usr \ ... --with-utempter \ --enable-double-buffer Could be more friendly.

Hmm, I confused xterm with urxvt.

Re: XTerm: It's Better Than You Thought

#40

I use a mixed environment. My servers are FreeBSD, OpenBSD, and about 5 different linux distros. I can only get consistent screen output if I use Xterm. rxvt, Alcrtty (sp?), Konsole, Gnome Terminal and all others that I have tried mungle ncurses, and/or other screen decorations (like using ASCII +------+, or TAB/Space, "decorations"). Even if I do get rxvt dialed in from one client, if I connect from a different work…

Most "modern" terminals are surprisingly buggy (for lack of a better word), that is, they do not conform to the VT100-series specs (and less documented, but well known quirks). Here's a look at some of them: https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...
Post reply on HN