Linux Terminal Emulators Have The Potential Of Being Much Faster

[reba]

a fun test would be to run mpv vo=tct since it does get limited by console often something like below would work

time mpv -vo=tct -profile=sw-fast -no-config -length="0:30" -hwdec=no -framedrop=no -untimed -no-audio video.mkv

This seems to be dependend on the terminal window size as it stretches the video.


Setting
- all the windows to the same sizes by "Win+CursorRight"
- having a same-ish font size so the same amount of content is shown
- all CPU governors set to powersave
- all CPU cores fixed to max 400 MHz
- best of two runs
results in:


foot:

$ time mpv -vo=tct -profile=sw-fast -no-config -length="0:30" -hwdec=no -framedrop=no -untimed -no-audio big_buck_bunny_720p_10mb.mkv
 (+) Video --vid=1 (*) (mpeg4 1280x720 25.000fps)
     Audio --aid=1 (*) (aac 6ch 48000Hz)

real    0m6,880s
user    0m15,617s
sys     0m1,774s​

Alacritty:

$ time mpv -vo=tct -profile=sw-fast -no-config -length="0:30" -hwdec=no -framedrop=no -untimed -no-audio big_buck_bunny_720p_10mb.mkv
 (+) Video --vid=1 (*) (mpeg4 1280x720 25.000fps)
     Audio --aid=1 (*) (aac 6ch 48000Hz)

real    0m10,392s
user    0m18,792s
sys     0m2,498s​

kitty (ligatures enabled):

$ time mpv -vo=tct -profile=sw-fast -no-config -length="0:30" -hwdec=no -framedrop=no -untimed -no-audio big_buck_bunny_720p_10mb.mkv
 (+) Video --vid=1 (*) (mpeg4 1280x720 25.000fps)
     Audio --aid=1 (*) (aac 6ch 48000Hz)

real    0m13,162s
user    0m20,084s
sys     0m2,410s​

KDE Konsole (ligatures enabled):

$ time mpv -vo=tct -profile=sw-fast -no-config -length="0:30" -hwdec=no -framedrop=no -untimed -no-audio big_buck_bunny_720p_10mb.mkv  
(+) Video --vid=1 (*) (mpeg4 1280x720 25.000fps)
    Audio --aid=1 (*) (aac 6ch 48000Hz)

real    0m25,155s
user    0m22,934s
sys     0m3,080s

For shits and giggles I also installed Gnome Console and WHAT THE....:

$ time mpv -vo=tct -profile=sw-fast -no-config -length="0:30" -hwdec=no -framedrop=no -untimed -no-audio big_buck_bunny_720p_10mb.mkv
 (+) Video --vid=1 (*) (mpeg4 1280x720 25.000fps)
     Audio --aid=1 (*) (aac 6ch 48000Hz)

real    3m56,688s
user    0m20,599s
sys     0m2,241s

It took Gnome Console 4 minutes to play a 30 second video other terminals needed less than 10 seconds to play.

There is probably something very wrong on my side, otherwise being faster than Console does not seem all too hard.



Second test with "time find /", same window size, 400 MHz, etc:

foot:

real    0m7,038s
user    0m2,039s
sys     0m4,793s​

Gnome Console:

real    0m25,768s
user    0m2,883s
sys     0m7,460s​

Holy moly.

[szymon_g]

For people who have been using the terminal for a while and are experienced enough to only require "basic" features; one hint is to use TERM=ansi. From this you can disable a lot of the tacky "aesthetic beginner" stuff in programs.

Also, if you haven't already tried it; give a bitmap font a shot. Not needing anti-aliasing is easier on the eyes, renders faster (even without a GPU) and just looks better in general. One that I find very effective is Spleen. Sidestepping anti-aliasing makes the whole experience quite different. Fast, crisp and "modern".

surely AA doesn't really have a major impact when run on anything even remotely modern?
bitmaps are great, but they suck: how can i go without shown in terminal?!?

but seriously, Terminus font rules

[Vistaus]

All I care for in a terminal emulator is whether it has Quake Mode support or not. If it doesn't, I ain't using it.

[kpedersen]

surely AA doesn't really have a major impact when run on anything even remotely modern?

To be fair, neither does GPU acceleration.

For remote rasters (i.e VNC) it does tend to compress better. Still largely unnoticeable though.

bitmaps are great, but they suck: how can i go without shown in terminal?!?
but seriously, Terminus font rules

Out of interest; Does Terminus show emojis in the terminal? I suppose it would be part of the unicode character set?

Really reducing AA is purely to see a crisper font. The other advantages are quite a bit less important.

[saboya]

Not sure if performance really matters past a certain point for terminals.

[reba]

Then it just doesn't properly support scaling because I get the giant cursor over the window like I do with other programs that don't support it property. Probably some goofy Gnome specific thing. I found kitty which supports everything I need with some tinkering.

From the foot readme:

Font sizes are apparently a complex thing. Many applications use a fixed DPI of 96. They may also multiply it with the monitor's scale factor.

This results in fonts with different physical sizes (i.e. if measured by a ruler) when rendered on screens with different DPI values. Even if the configured font size is the same.

This is not how it is meant to be. Fonts are measured in point sizes for a reason; a given point size should have the same height on all mediums, be it printers or monitors, regardless of their DPI.

That said, on Wayland, Hi-DPI monitors are typically handled by configuring a "scaling factor" in the compositor. This is usually expressed as either a rational value (e.g. 1.5), or as a percentage (e.g. 150%), by which all fonts and window sizes are supposed to be multiplied.

For this reason, and because of the new fractional scaling protocol (see below for details), and because this is how Wayland applications are expected to behave, foot >= 1.15 will default to scaling fonts using the compositor’s scaling factor, and not the monitor DPI.

This means the (assuming the monitors are at the same viewing distance) the font size will appear to change when you move the foot window across different monitors, unless you have configured the monitors’ scaling factors correctly in the compositor.

This can be changed by setting the dpi-aware option to yes in foot.ini. When enabled, fonts will not be sized using the scaling factor, but will instead be sized using the monitor’s DPI. When the foot window is moved across monitors, the font size is updated for the current monitor’s DPI.

This means that, assuming the monitors are at the same viewing distance, the font size will appear to be the same, at all times.

Note: if you configure pixelsize, rather than size, then DPI changes will not change the font size. Pixels are always pixels.

Maybe give it a try.

If you are having problems with the cursor size, you might have to set:

XCURSOR_SIZE=24

because (link)

Cursor size means different things on x11 and wayland. On X11, it's in device pixels. On Wayland, the cursor size is in logical pixels and kwin upscales it as needed. You need to use 24 cursor size on wayland.

But this would indicate foot is not running as wayland, which would be very strange.

[rlkrlk]

What I'd really like to see in a terminal emulator -- and this would require cooperation from the overlying shell -- is the ability to save and restore the entire state of each session, including shell history (which is currently per-user only, not per-session), terminal output up to the specified number of lines, environment variables, and shell variables (including functions). This would allow, with certain exceptions, restoring the entire session. Currently other applications such as browsers, LibreOffice, and even emacs allow saving and restoring sessions, but terminal emulators don't. I spend a lot of my time on the command line, so this makes things like system updates a big PITA.

There would be certain obvious exceptions, such as foreground and background jobs, such as ssh sessions, although using something like screen on the remote end could even help with that.

Performance of terminal emulators hardly matters to me; they're all plenty fast.

[S.Pam]

I'm pretty happy with Kitty. It's my go to terminal these days.

[Snaipersky]

What I'd really like to see in a terminal emulator -- and this would require cooperation from the overlying shell -- is the ability to save and restore the entire state of each session, including shell history (which is currently per-user only, not per-session), terminal output up to the specified number of lines, environment variables, and shell variables (including functions). This would allow, with certain exceptions, restoring the entire session. Currently other applications such as browsers, LibreOffice, and even emacs allow saving and restoring sessions, but terminal emulators don't. I spend a lot of my time on the command line, so this makes things like system updates a big PITA.

There would be certain obvious exceptions, such as foreground and background jobs, such as ssh sessions, although using something like screen on the remote end could even help with that.

Performance of terminal emulators hardly matters to me; they're all plenty fast.

I would think that everything could be reasonably contained in a session###.var containing variables and command history, and a session###.buf containing the saved output. No shell integration required, just a way to select a session (and maybe snapshot it) in the terminal.

[elduderino]

/wave Author of termkit stuff here

First off, the Termkit prototype was just for me to figure out what "best case" performance would be while I go try to fix bits of VTE. It's good to have a trajectory to shoot for when doing optimization work.

It took Gnome Console 4 minutes to play a 30 second video other terminals needed less than 10 seconds to play.

There is probably something very wrong on my side, otherwise being faster than Console does not seem all too hard.

There is nothing wrong with your setup.

The VTE port to GTK 4 was _VERY_ minimal and basically just used a Cairo fallback render node in GTK 4. That is worst possible case because the OpenGL renderer in GTK 4 has to upload the surface texture on every frame. This is precisely what I set out to fix (because I consume VTE for GNOME Builder's terminal as well). The patches I put together for VTE (which still need work to be upstreamed) use GskTextNode with the goal to get a considerable amount of caching and use the glyph texture atlas properly. Doing so results in a color+blit as a single GL shader program. You don't even have to change programs to draw the rectangles, emoji, etc. It's one large VBO and glDrawArrays().

Generally speaking, I don't work on VTE except the most basic of patches, but I did write a lot of GTK 4's OpenGL renderer, wrote one of the GDK platform back-ends, helped made text scrolling smooth at high frame rates, and the profiler we use to optimize the compositor and apps in GNOME. So I have very practical experience at what to do to "cut through the bullshit" at every one of those layers.

A lot of emulators out there focus on how to do the drawing really fast. Well we already have that solved in GTK. Some of them focus on tracking damage areas to keep updates minimal. Again, we already have that for free in GTK 4 based on the render tree diffs. So again, don't waste time doing that work.

The other optimizations are all pretty normal stuff. Keep data-structures flatter to avoid pointer chases. Read PTY data directly into your chunked ring buffer. Be very careful in your VT parser to avoid doing things per-character. Keep styling attributes in as fast to store format as you can so you can skip over the vast majority that never gets displayed. Only wrap text for the region you can see, do the rest in the background. Keep render nodes around for an extra frame so you can get _VERY_ fast render tree diffs from gsk_render_node_diff() using pointer equality... Anyway, nothing too outrageous IMO.