Hacker News Reader

Comment by chungy | Hacker News Reader

libvte is a big reason that GNOME Terminal tends to be faster than competing terminal emulators, including xterm and rxvt. One of VTE's tricks is that it doesn't bother painting the screen if the contents are going to be overwritten in the next frame anyway; you can scroll through megabytes of data in fractions of a second this way.

The idea that it's slow, that's new to me.

View on HN

I have a 655MB file with 1.5 million lines of lorem ipsum. I timed a cat in several terminal emulators. For this simple test, gnome-terminal beat xterm a little bit but wasn't anywhere close to the rest:

  foot             0m9.410s
  alacritty        0m16.881s
  konsole          0m36.737s
  gnome-terminal   1m1.096s
  xterm            1m16.919s

Foot has an page that explains when and why it's fast, and also when it's not, compared to alacritty.

https://codeberg.org/dnkl/foot/wiki/Performance

There can be distinctly different run speeds between bulk entry dumb terminal and opcode heavy tui behavior.

https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...

And I don't really care that much but I will say that while it is a bit of a dog in the bulk display race, no one beats xterm in the keyboard latency contest.

Enabling fastScroll in xterm makes it competitive in the "bulk display race". It's disabled by default because who cares how fast a huge file can be displayed on stdout in real-world usage?

Glad this Termkit prototype work is right on track then. Generated a 655MB lorem text file and it came out at 0m8.186s.

I've heard various things about VTE over the years including:

1. They "like" xterm because i get value out of screen tearing and feeling like they can catch what is scrolling by (even though it's literally seconds slower) 2. They don't like the 40 fps cap it currently has because it predates reliable access to vertical sync information in applications. 3. They are using the GTK 4 port which draws with cairo and uploads surface data on every frame update.

The patches I put together for VTE this week (while having some down time with Covid) address a portion of that by making it render fonts/rectangles/emoji/etc on the GPU using GTK's OpenGL renderer (which I also wrote a large portion of).

Years ago, the biggest bottleneck with VTE was that it was storing the scrollback history on disk (https://bugzilla.gnome.org/show_bug.cgi?id=631685). Eventually support for an in-memory scrollback buffer was added, which improved the situation considerably.

Long dumps of output with VTE seems to be fast enough, at least with a barebones program that creates a VTE widget and doesn't do much else. But Gnome Terminal was noticeably slower than my naive program, last time I tried it. I don't know why.

xterm has a command line flag that enables the same speed hack. It's disabled by default. The major difference between xterm and the others is that xterm emulates a terminal and libvte-based emulators, Kitty, and the like are more like shitty xterm emulators. Accuracy is preferred over speed, and certainly over silly microbenchmarks like cat'ing a 655 MiB file to stdout and timing how long it takes to display.

Alacritty is wildly and obviously faster than gnome terminal in use. It's super clear when you try it out.

I think this does almost every terminal, including rxvt (with the notable exception of Linux console).

Reply on news.ycombinator.com