Linux Terminal Emulators Have The Potential Of Being Much Faster

[Hohlraum]

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

Have you found a way to make tabs use all available horizontal space (and in turn be the same width)?

[mercster]

Pointless. But of course, Phoronix commentors think this is a travesty of justice not to be pursued.

[fitzie]

Comparing terminal performance/speed without adding foot (git) (arch) to the mix is disqualifying from the start.

It's probably the quickest redrawing and most responsive terminal I ever tested (and those were quite many with the usual suspects as alacritty, kitty, etc.).

I don't know how I'm overlooked foot before. I've even had it installed. It does look pretty nice. I'm a long term xterm user, so it doesn't take much for me to want something else, but there's a few things that foot lacks that I want before I switch.

1) when you change font size, it should keep the same dimensions in chars row/cols (i.e. make the window bigger or smaller). It's nice that foot reflows text when you resize, unlike xterm which will truncate it's buffers.
2) need some sort of menu for the occasional runtime settings flipping. Disabling scroll to bottom on tty ouput is the only one I really use from time to time on xterm.
3) I want my xterm replacement to have tabs and hopefully split terminals as well. (I'd consider using screen/tmux/zellij if I was still using a vt220, but since I have a graphical desktop, I want to use it, and not replace my GUI with ascii art)

[EphemeralEft]

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

Right? I pretty much only use SSH in the terminal, and that’ll be almost exclusively limited by the network.

[EphemeralEft]

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

I love Kitty, but it’s incompatible with my peripherals; it constantly presses my keys and turns off my monitor. And the garbage collection is also pretty unpleasant. If the interface wasn’t so nice, I’d have switched to Doggy.

[ayumu]

Zutty FTW: https://tomscii.sig7.se/zutty/

And remember latency matters more than throughput.

[rlkrlk]

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.

The shell integration is needed to reliably extract the names and values of all variables and possibly to restore them. It might be possible to use HISTFILE to handle the history part, but I think the rest will likely need a bit more integration (or at least defined interfaces).

[reba]

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



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.

Thank you very much for an inside glimpse. Which of your work might be up-streamable?

I suppose the sources or a deb package are not available for a small test run?

[Quackdoc]

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:

...

ouch, gnome console got hammered here

[NotMine999]

I love Kitty, but it’s incompatible with my peripherals; it constantly presses my keys and turns off my monitor. And the garbage collection is also pretty unpleasant. If the interface wasn’t so nice, I’d have switched to Doggy.

Have you tried Hamster? It can be insanely fast at times, but only in circles.