Modal? The various input modes. Think of them as if you're using vi/vim, except that it's a terminal. Insert mode is just like every other terminal. Press Ctrl+Shift+Space to move to normal mode (configurable) and use many of the vim motions you know to navigate through your history. The supported keys go way beyond what Termite and Alacritty implement. You might find that you'll never need a mouse again (or almost never). For anything that's missing, please file a ticket, and we're going to work on that.
> Certainly I’ve wished the things I run in it were faster, but that’s a different story.
I absolutely agree. Most of the performance metrics that people talk about is beyond visual perception anyways. In Contour we've only done some optimizations the way we did it because it was actually fun to implement, and a nice little challenge.
While I myself feel like i'm pretty much hard-lining into the terminal, I accept that some things are better left to the GUI world, e.g. daily web-browsing I should not be forced to use w3m or the likes. :)
This doesn't make sense. WebGL is as GPU accelerated as the other young'ish GPU accelerated terminals, except that they're not running in the browser, which should(tm) make them run faster.
On the other hand, rendering is just one thing to benchmark, there is input latency (already mentioned in this thread here somewhere), but also (terminal / PTY) bandwidth throughput. This is three categories where 2 of the 3 are not related to "GPU acceleration" at all. :)
Hey, we are using Qt only on the pure frontend GUI side. The rendering itself is using FreeType + HarfBuzz independantly of the GUI.
We chose this model explicitly to still be free to replace Qt with something else in the future - iff we have to.
The reason behind that decision is, that we actually started with GLFW3, and epically failed, because GLFW3's input model was inferior and the API that I needed was actually marked deprecated by the GLFW3 devs and they also stated that their input model is not good and needs a rework. That led me to the decision to look around and find something else.
I only wanted to keep the GUI framework dependency as minimal as possible.
We sadly do not have BiDi support just yet, I'd actually love to have that. So far I only know of 2 terminals capable of this: mlterm and gnome-terminal.
Unfortunatily I lag the skills of hacking this in except doing it naively. I'd be more than happy for external contributors knowledgable enough in the domain of BiDi, to help us out here. :)
To be honest, refterm was a bad idea to begin with. It's not a terminal, and it eventually also stated that in its README.md. Not to mention, that you - by definition - can't compare apples with pies. refterm is not a terminal and thus cannot be compared with a terminal WRT speed. It simply prove a point on rendering speed, at a cost of breaking a lot of the rules a terminal emulator has to obey to. Most notably is `DECAWM` (DEC Auto-Wrap Mode) that was not properly implemented. The author once stated in a Twitch stream that he simply didn't understand that and thus skipped that part. However, that is the part where it will get complex (and thus slow) if you want to get it right for non-trivial US-ASCII characters, such as complex grapheme clusters (family Emoji most interestingly) or even VS16 (variation selector changing the width of the base code point from narrow to wide). The latter point isn't standardized by DEC anyways, but the younger terminals all try to make the terminal more appealing to the younger Unicode crowd that do expect complex Unicode to render "just fine" (or "as fine as it gets"). refterm also had a hard coded 4k line length limit and just hard-cut off there instead of properly counting for the wrap.
TL;DR refterm (while positively inspirational to a few) was harmful to the terminal community, because it was fooling a lot of people with false metrics that the users simply believed in, without questioning.
simply put, yes. but I know very well that performance can be measured in many different dimensions and ways. I optimize for speed for my own personal use-cases (vim should be fluent as well as notcurses-demo as well as cat'ing large output).
Especially cat-style benchmarking is what YT-channels like to do, right next to `time tree /`.
We do not claim to be THE fastest (unless you find out why, but pssst, don't tell anyone), because I do not want to start a performance war on some metric that is almost useless for the regular and even power user.
Input latency, oof, last time I actually took the time to check, it was similar to KDE konsole. I used some Java based tool to measure this, IIRC I've got this from an LWN article. But now, I'm not having the time to do this again, especially since I feel like there's more important stuff on our plate, that I really want to get done in 2023 (e.g. getting out the next stable release). :)
If anyone of the power users opts to re-visit perf benchmarking on the modern TEs compared to the classic ones, I'd be one amongst the first to gladly read though ;)
How did you install Contour and what is the TERM environment variable set to and is your terminfo properly resolved? I just asked someone with an AMD/NVIDIA card to try out nvtop inside Contour and it worked. So I assume maybe there is something fishy with your TERM/terminfo configuration.
> In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering,
Nothing is perfect. Many thanks for trying though. If you don't mind, maybe you could file a report in github.com/contour-terminal/contour/issues/ such that we know about it, can track it, and also, report back to you, once it's improved?
Generally speaking, it's hard to say that rendering is that bad, because we simply use FreeType for glyph rasterization as well as Harfbuzz for text shaping. That doesn't mean it's perfect. I know that not everybody likes lcd subpixel rendering in Contour, and that anti-aliasing (AA) methods are generally highly subjective on what the best AA method is. We implement multiple such that most users should find what they like the most.
If that still doesn't fit, I'd like to know about it, so we can hopefully fix it, just in case it is a bug on Contour's end.
> and like always it uses at least 5 times less memory
That's not a good metric to look at, at least it's not enough info to judge about. I recently read a guy comparing the memory resource usage of many terminals when having 2,000,000 lines of history configured and found Contour to be the winner here. This doesn't mean much though. I think just looking at the memory consumption is not enough to reason about it. I do agree however, that it should not blindlingly grow over time to something unreasonable. We try not to carelessly allocate any resource, so I'm pretty certain that we're doing "okay" in terms of RAM requirements.
I will find some time to write an issue about the rendering.
And you're right, contour is doing okay in terms of memory, especially compared with other modern terminals. It's just that the first run after built uses already 250mb, and I think that when I will setup some fonts and run a few panes inside it will probably go higher. But if it stays around this number, it's really fine.
While I personally find your comment quite insulting, I think that we have pretty brought support for various mainstream Linux distributions and also release binaries, including for MacOS and Windows. For Arch there's even an AUR, and for Fedora it can be also officially installed via `dnf`. Everyone else can grab a binary from the release page.
If there is anything else that you find is missing, I am more than curious to hear about it and we'll evaluate the priorities to include it. Other than that, I'm inviting you to contribute. :-)
Modal? The various input modes. Think of them as if you're using vi/vim, except that it's a terminal. Insert mode is just like every other terminal. Press Ctrl+Shift+Space to move to normal mode (configurable) and use many of the vim motions you know to navigate through your history. The supported keys go way beyond what Termite and Alacritty implement. You might find that you'll never need a mouse again (or almost never). For anything that's missing, please file a ticket, and we're going to work on that.
> Certainly I’ve wished the things I run in it were faster, but that’s a different story.
I absolutely agree. Most of the performance metrics that people talk about is beyond visual perception anyways. In Contour we've only done some optimizations the way we did it because it was actually fun to implement, and a nice little challenge.
While I myself feel like i'm pretty much hard-lining into the terminal, I accept that some things are better left to the GUI world, e.g. daily web-browsing I should not be forced to use w3m or the likes. :)