4 ms·

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'

by chungy 3y ago

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.

audidude 3y ago
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).
rascul 3y ago
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 https://codeberg.org/dnkl/foot/wiki/Performance
- audidude 3y ago
  Glad this Termkit prototype work is right on track then. Generated a 655MB lorem text file and it came out at 0m8.186s.
- somat 3y ago
  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-of-Zutty#performance-and-resource-usage 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.
  - bitwize 3y ago
    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?
zajio1am 3y ago
I think this does almost every terminal, including rxvt (with the notable exception of Linux console).
cout 3y ago
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 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.
bitwize 3y ago
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.
seanhunter 3y ago
Alacritty is wildly and obviously faster than gnome terminal in use. It's super clear when you try it out.

by chungy 3y ago

audidude 3y ago

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).

rascul 3y ago

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 https://codeberg.org/dnkl/foot/wiki/Performance

audidude 3y ago
Glad this Termkit prototype work is right on track then. Generated a 655MB lorem text file and it came out at 0m8.186s.
somat 3y ago
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-of-Zutty#performance-and-resource-usage 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.
- bitwize 3y ago
  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?

zajio1am 3y ago

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

cout 3y ago

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 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.

bitwize 3y ago

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.

seanhunter 3y ago

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