KiTTY is useful for Windows users but are any significant amount of people using it on Linux? I would imagine that aside from people using the default terminal emulators that come with their distro or desktop environment like xterm, gnome-terminal and konsole, the most widely used terminal emulator on Linux would be urxvt.
Yeah I've used it on OS X. It renders fast and is the most responsive terminal I've tried (alacritty, iTerm2, Terminal.app). Its font rendering isn't super optimal, and it's a little rough (no hotkeys for zooming, etc.), but it's really your only option if lag bothers you.
Nowadays I just use terminal in gvim. It solved like all of my problems. Should've known Vim would save me again haha.
While a GPU accelerated terminal emulator sounds great on paper, do keep in mind that GPU acceleration doesn't really give you that much in terms of raw performance. You still have to render glyphs individually, almost always on CPU. So, the reality is probably more that GPU acceleration gives you more flexibility, rather than giving you performance. Anecdotally, I just ran this and it takes roughly twice as long to slog through my dmesg as gnome-terminal.
That said... pretty cool. I don't know if there already existed VT100 emulation written in Go, but it doesn't hurt to have that. Plenty of applications might want to embed a terminal or otherwise have terminal emulation.
There's probably lots of room for optimization, for example currently it sets and resets all sorts of GPU state on each print call, for each character, which is rather expensive:
Speaking of the main loop, for every columm and every row:
cx := uint(gui.terminal.GetLogicalCursorX())
which in turn calls another function -- move that outside of the loop and do it once. Generally buffer values that don't change and get used in loops, instead of fetching them by calling functions on each iteration.
Also, while it may not matter much in this case unless there are other sources of GC churn, just because I noticed it: don't create an array for the vertices for every character to then throw it away and recreate it, have one and keep reusing that.
Go's GC is deliberately non-relocating, which precludes being generational. https://blog.golang.org/ismmkeynote The repeated state in question might be benefiting from escape analysis, but I can't tell from a cursory examination.
Sure, but almost free GC is free in the same way throwing away 3 cents is almost free. Once it adds up enough to cause lost frames, anyway. Just like a straw practically weighs nothing, except when it's the straw that causes the camel to miss a frame.
In this case, I also doubt it would make a difference by itself, but I haven't looked at all of the source, so I just mentioned it as something to maybe watch out for. Also, every bit of GC you can super easily avoid "buys" you room for GC that would make the code more complicated to avoid. Waste not, want not :)
I've been using alacritty, another new-ish GPU accelerated terminal emulator, and I can confirm that its performance is better than gnome-terminal or similar. So at least there is something to this idea.
> Alacritty is the fastest terminal emulator in existence. Using the GPU for rendering enables optimizations that simply aren't possible in other emulators.
I wonder though why people need fast terminal emulators (?) I'm using "xterm" and I haven't found any issues with speed.
I'm using only alacritty for the past year and at least on MacOS the rendering latency is in another level. The response is super fast while scrolling through text on less or vim, changing windows on tmux seems to happen instantly, even typing seems to happen without a delay compared to iTerm or Terminal.
One thing that I thought would justify this is that they don't support scrolling text by themselves and to have it you're required to rely on tmux or screen.
In my experience, urxvt is both faster and uses less memory than xterm by a good margin, although there's not such an appreciable difference on a modern system. Gnome Terminal, on the other hand, is beyond slow, far worse than the still slow but acceptable Konsole.
In those cases, I usually redirect the output to a file, so I can search through it.
Another approach is to run "screen", which has several advantages: (1) not all text needs to be written to the terminal, only the text when you actually look, (2) you can open the computation on a different computer later (e.g. perhaps at home to check if everything is ok), and (3) if you accidentally close the terminal the computation keeps running.
In both cases, my terminal emulator does not need to be fast, really.
My biggest issue with speed in the terminal comes from network latency (which is difficult to fix).
Oh, and while you are at it, have a look at mosh as well. Mosh bills itself as the ssh alternative for mobile, intermittent connections but it does take the idea of 'not all text needs to be written to the terminal, only the text when you actually look' even further.
Mosh also has lots of network latency hiding tricks up its sleeve.
Rendering speed shouldn't matter in this case because the terminal shouldn't be trying to render every single line which is sent to it. The terminal should just process the stream and commands, and real updates to the screen.
If you pre-render the glyphs to a texture, you can draw them to the display as fast as your GPU can go. Changes in font size or face mean you'd have to pre-render them all over again, but that's still not terrible.
With a fixed width font in a single size surely caching glyphs goes a long way? Most of the characters probably come from a small set of characters, and obviously a cache can support full unicode. I guess you couldn't do subpixel hinting but an alpha blended character can be tinted any colour for FG/BG.
You can do caching with any renderer, GPU or not. Almost any text renderer caches glyphs to some degree. Of course, even fixed width fonts can have things like ligatures and composite characters which complicate matters. Rather than caching individual code points, you'd really need to cache something more like individual grapheme clusters.
Subpixel rendering is tricky, but should be possible to do with shaders. You could just render to a normal single channel texture at 3x the horizontal spatial resolution (basically, stretched 3x horizontally) then when rendering move 1 pixel across the glyph rendering for each subpixel, alpha blending individually.
> You still have to render glyphs individually, almost always on CPU.
How do you figure? As I imagine it you would stream the buffer to the GPU and render it with a pixel shader. Even if layout or glyph calculation is done on the CPU it should be highly cacheable.
GPU acceleration doesn't change the dynamics of caching glyphs. Existing text renderers already cache aggressively. Also, worth noting that caching the rendering of individual code points won't work effectively even in all cases for a terminal, because of diacritics, ligatures, etc.
Of course it's all pixels. You can do it all in pixel shaders. But of course, it's a lot more complicated than it seems. Supporting RTL requires some pretty advanced layout logic. Supporting OpenType ligatures also requires some pretty complicated, stateful logic. And you probably want to support "wide" glyphs even for a fixed width font, which are present in terminals where you are dealing with, for example, kanji.
If you want subpixel AA, that's another complicated issue. If you want to be able to do subpixel AA where glyphs are not locked to the pixel grid, you will need to do more work.
If you want to be able to render glyphs on the GPU purely, you'll need to upload all of the geometries in some usable form. Most GPUs don't render curves, so you will probably turn them into triangles or quads. That's a lot of work to do and memory to utilize for an entire font of glyphs.
You also might think you could utilize GPUs to perform anti-aliasing, but the quality will be pretty bad if done naively, as GPUs don't tend to take very many samples when downsampling.
Since a lot of the work is stateful and difficult to parallelize, doing it on CPU will probably be faster, that way you only pay the latency to jump to the GPU once.
> Since a lot of the work is stateful and difficult to parallelize, doing it on CPU will probably be faster, that way you only pay the latency to jump to the GPU once.
You can still easily cache the glyphs post processed, especially if you don’t use subpixel AA. There isn’t that much state to a scrollback buffer post glyph processing.
I don’t get the resistance to this type of rendering when at this point there are at least three major monospace glyph rendering libraries implemented for the GPU, and I bet there are dozens I don’t know about.
No such resistance here; I've written text renderers myself. I'm just pointing out that it's not simple and there aren't trivial performance gains. Like I said, you can't really just cache codepoints. The way this particular terminal emulator does it, it's keeping a cache of individual codepoints. Even forgetting OpenType ligatures, this also won't work for things like diacritics.
it's great to see more terminal emulators, especially ones that have good unicode support and are trying to be faster than the average garbage.
There's at least one other terminal emulator that does things akin to the image-catting and viewing colors when you click them, namely terminology [0].
There's also at least one other that uses opengl for faster rendering (alacritty [1]).
I don't know of any other that do both these things; use opengl for speed and also innovate in interactivity.
Sixel is great. But you could also interpret the headers of common image file formats as terminal escape sequences, so that you can directly "cat lena.png" and see the image. Now, that would be a real hack!
The terminal couldn't do that as it wouldn't know the difference between a user typing `cat lena.png` into Bash from typing the same sequence of characters into vim (for example).
This is why there are separate commands like `icat` which will output ANSI escape sequences for rendering a PNG. Unfortunately a great many of these are terminal specific (iterm, terminology, kitty and VT200/VT300 (sixel) all have their own unique escape sequences. The closest to a standard we have is sixel and, frankly, I don't think it's that good on modern systems[1]). So you end up with different command for each "standard" you want rendered.
The approach I've taken in my own $SHELL is to have a builtin command like `cat` (I call it `open`) and that auto-detects which terminal emulator you're running and picks the right encoding to match what is supported by the terminal (if no standard can be auto-detected, then it falls back to ANSI art using coloured blocks). However the issue with that is now people need to run new custom shell instead Bash / Zsh / whatever. But the logic behind the auto-detection is really quite simple so that could be written it's own standalone tool.
[1] sixel re-encodes images in character blocks of 6 pixels. Where as iTerm, Kitty and Terminology send the image as is over the terminal via a base64 encoded string. All those solutions are inlined via ANSI escape sequences though.
> The terminal couldn't do that as it wouldn't know the difference between a user typing `cat lena.png` into Bash from typing the same sequence of characters into vim (for example).
This is not what I am talking about. I mean the binary headers inside png, jpg, tiff files, etc. These binary sequences can be easily interpreted as terminal control sequences, and they are very unlikely to appear otherwise. For pnm files I agree that the situation is a bit more delicate, as these sequences are likely to appear in the wild (e.g., in the pnm man page for example).
This is an inevitable feature of the perfect terminal. The alternative is showing the binary contents of the image file in ASCII, which is always undesired.
Not just undesired; it can sometimes play havoc with your terminal session. I've had tmux status bars break; bash prompts go "weird" and all sorts of other glitches before when I've accidentally piped binary data to the STDOUT.
I'm very tempted to fork Aminal and have a play with your idea.
That would be lovely! I do a lot of image processing using unix pipes, and when I forget the "|display" at the end it breaks everything.
Notice that you do not even need to use sixels in your case. Since you control the rendering, you can simply put the pixels of the image on a rectangle (that allows paning and zooming, for example), and move the cursor below it.
It wouldn't be until I'm off for Christmas holidays (at the earliest) though. I don't have a whole lot of time left between work and family; and have a few projects on the go as it is already.
It’s so that we, hackers, can see if it’s worth looking at the source. Personally I look at the source of Go or Rust projects because I’m not top proficient in the languages and it’s a way I can learn idioms.
In fact, since this is for a developer audience, I’d wonder why you wouldn’t say what language something is in.
It's great that there's a hotkey to web search for the current selection, but I'd not be surprised to see people requesting that it not be google. Know your audience and all that.
This may be referring to running under Linux with a high DPI monitor - a lot of programs which are naïve about this don't scale properly and are teeny-tiny.
Since it's Linux compatible it's much simpler to support a global standard like open gl and mostly work everywhere rather than use whatever apple is pushing now and also support open gl anyway for Linux.
I assume they're open to contribution if someone wants to add Metal support for mac osx.
I knew this would be created eventually but I was thinking it would just be a shell. This looks impressive at first glance, implementing everything with OpenGL.
I would have loved to see someone with a plan9-golang background creating a modern 9term-like "dumb" terminal.
One that is mostly an editable text buffer with mouse plumbing capabilities.
Nowadays, terminals within vim/emacs is what's closer, feature wise. Not quite dumb though.
Edit: it's GTK that provides multithreading functionality, not VTE itself.
VTE based terminals are actually multithreaded globally, so you only ever have one process regardless of number of tabs/windows open.
But I agree, VTE is something I avoid ever since the scrollback fiasco. (For the uninitiated: the library wrote all scrollback to disk, which is not something end-users might expect security wise. Scrollback is encrypted now, but it appears you still cannot disable writing to disk, as e.g. the output of dmesg, consisting of 62210 bytes of output on my machine, causes 5-digits of bytes to be written each time on any VTE-based terminal I've tried even with "infinite" scrollback disabled. And none appear to honor TMPDIR).
The O_TMPFILE flag is just an anonymous file as far as I understand. From that source file, VTE uses glib, particularly g_get_tmp_dir() and g_file_open_tmp() (which uses the latter), which claims to honor TMPDIR according to the docs: https://developer.gnome.org/glib/stable/glib-Miscellaneous-U...
Perhaps a terminal emulator is unable to read variables exported in .bashrc, as the terminal is started prior to executing the shell.
I prefer tmux windows; I have 1-3 terminal emulators and 10-30ish windows/tabs (not counting splits/panes), all on 1 tmux session via `tmux new-session -t $SESSION`. Acceptably navigatable via prefix-[1-9] and prefix-w (which gives a list to jump to).
I find tmux makes less sense within a tiling window manager because then you have two contexts effectively providing the same functions (or three, if you use vim :split (or four, if you use tilix)).
I also use a tiling wm, and use tmux. The main reason is that it means I can easily transition to using the same tool when working with remote machines using mosh. Personally, I've always felt odd when trying to use i3 tiling for terminals (maybe that's because I used tmux before I used i3).
