7 ms·

Linux terminal emulators have the potential of being much faster

pmontra 3y ago
Fast is good but given that any terminal is fast enough to type commands and scroll around, convenient is even better. Example: I went with tilix months ago and eventually switched back to Gnome terminal because tilix froze sometimes. Furthermore tilix doesn't have a way to bind commands to a profile to run them when opening a terminal with that profile. The freeze is of course 99% of my switching back.
- throwaway02y 3y ago
  Never experienced any freezes with tilix and I use it daily for years now. It's abandonware though.
  - audidude 3y ago
    It's still GTK 3 using VTE and so doing the drawing with Cairo. It (VTE) has a lot of optimizations that made sense when we didn't have working GPU drivers. But for GTK 4, we can do things much differently and faster.
whalesalad 3y ago
alacritty is fast but kitty is faster. glad to see us racing to the top in this space.
- tmtvl 3y ago
  They're both leaving practical performance on the table by not implementing VT420 (or better) control sequences, though. So whatever gains you get from them are lost by applications needing to do more work. For example, tmux uses DECLRMM to restrict scrolling to the active part of horizontally split panes, and as neither Alacritty nor Kitty implements DECLRMM tmux will have to do more work to get the same effect. The author of Zutty has a writeup about it: https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-of-Zutty https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...
  - deleted 3y ago
    [deleted]
  - somat 3y ago
    as a contented xterm user, none of these "modern gpu accelerated terminals" really excited me. But the care shown in correct output by the author really grabbed my interest. I probably won't change, as I said I like xterm, but I am going to try it out.
CJefferson 3y ago
Looking at this, I’m reminded of early clang, which was often 5 or more times faster at compiling C++ than gcc, while handling maybe 95% of C++ code. While clang is still in my experience faster than gcc, it turns out handling that last 5% correctly can knock a lot off your performance. Of course with terminals it might turn out you don’t need that last 5%, or you really can get all the way and keep the speed, but this isn’t the first project dedicated to making “the fastest terminal”.
- jchw 3y ago
  The way I see it, modern terminal emulators are kind of like multimedia applications, they've got a frame budget. Today a lot of them don't necessarily spend that budget wisely. I think there is a legitimate point here. Compilers could be faster, but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. In my opinion, not so for terminals: I'm pretty sure you could analyze the amount of time spent rendering in a terminal emulator and come to the conclusion that a lot of it is essentially wasted, with exception of a few more modern terminal emulators that considered this more deeply. This is in part due to the nature of the outputs of terminal emulators vs compilers; like for high throughput, it would be good if the terminal emulator spent as little time as possible processing things that won't ever actually make it to a frame. Compilers are mostly not interactive though, and don't have the luxury of deciding to simply not do something because nobody is looking.
  - db48x 3y ago
    > but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. I don’t think that there’s any evidence that this is true. In fact, the performance of the Rust compiler has continually improved over the last five years while _adding_ new features, and not by removing anything. <https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html> All a C++ compiler needs to do to get similar results is to have a team that does nothing but performance work, and is actually rewarded for it.
    - 3y ago
jchw 3y ago
Although people wonder why anyone cares about performance in terminal emulators, it's more about caring about inefficiency in terminal emulators. There are some legit cases where performance actually does come into play, like with high-throughput. Sometimes it's not even necessary, such as when terminal emulators do more work than they should processing data that won't be displayed; those things have the potential to impact the experience even when there is plenty of CPU and GPU to spare, like on a desktop machine. However, it's not just performance. It's also energy usage, particularly on small things like the Pinephone. Linux being an OS where the terminal is as powerful as it is, it's really good to see a high level of attention to detail going to terminal emulators finally. Terminal emulators should be extremely robust and extremely efficient; and finally, they're getting pretty close.
- kgwxd 3y ago
  I never really cared, but when I first dropped into a proper terminal in Ubuntu many years ago using ctrl+alt+n, or whatever the combo is, it really felt like the characters were appearing on the screen before I even touched the key. That’s when I learned emulators have a noticeable lag. I still don’t care much, but it sucks to know it’s there, no matter how much I spend on hardware.
  - pmontra 3y ago
    Ctrl-Alt-F3 to console and Ctrl-Alt-F2 to go back to the GUI?
    - Izkata 3y ago
      Where the GUI is has changed over the years/by distro, so I use Ctrl+Alt+(right arrow) to cycle between them until I find it.
  - mrob 3y ago
    xterm has no built in lag (your compositor will introduce some, but it's possible to disable compositing if you use Xorg). Kitty can be configured to have practically identical lag to xterm.
kzrdude 3y ago
It seems like he's not even sharing the code, which is unfortunate if Alacritty or others want to learn from this. I guess that's a personal choice, but is it in the spirit of fosstodon (the mastodon instance he's on.)?
- audidude 3y ago
  I already maintain two dozen GNOME projects. I wrote a huge amount of GTK's OpenGL renderer, the profiler we use on GNOME, GNOME Builder, and a huge amount of other parts of GNOME. I've even started to fix the library that people will actually use (VTE) instead of fragmenting communities with some other project. My commitment to "FOSS" is not up for debate. I've written in multiple places what it takes to get stuff that fast. If that isn't enough for any of those projects, I'm happy to take money in exchange for my time.
lylejantzi3rd 3y ago
This reminds me of the kerfuffle Casey Muratori caused last year when he dared suggest the windows terminal could be faster. https://twitter.com/cmuratori/status/1523024109831041024 https://twitter.com/cmuratori/status/1523024109831041024 https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm
- fbdab103 3y ago
  I feel like you are really under-selling that entire drama. It started with Casey pointing out some slow terminal behavior[0], to which he received unreasonable flack, including this choice quote, >I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively… Casey then spent a weekend and produced a couple thousand line terminal emulator which seemed feature complete(? probably missing some bells and whistles), but blew away Windows performance. A year later, Microsoft released a patch, roughly incorporating some of Casey's suggestions, and did not credit him for anything[1]. Edit: This[2] seems to be the much bigger Hacker News discussion about the topic instead of [1]. If nothing else, [2] has a repeatedly edited post by the Microsoft author where attitudes are on full display. [0] https://github.com/microsoft/terminal/issues/10362 https://github.com/microsoft/terminal/issues/10362 [1] https://news.ycombinator.com/item?id=31372606 https://news.ycombinator.com/item?id=31372606 [2] https://news.ycombinator.com/item?id=31284419 https://news.ycombinator.com/item?id=31284419
  - dundarious 3y ago
    To give a more complete story, they did belatedly credit him and others, in a later edit. Still a very poor showing from the relevant people at Microsoft.
  - psd1 3y ago
    Wait, what? I read through that entire discussion. I do agree that the quote you pulled out was not ideal, but that's the only thing in there that's even remotely abrasive. Skyline in particular took great pains to provide context of why the performance issue was the way it was. Where's the flak, exactly? (FYI, no "c" in "flak")
sylware 3y ago
I may write my own but wayland, pure CPU rendering, assembly (x86_64/risc-v)... but... I am still on other projects.
mrob 3y ago
Meanwhile, all GNOME-based terminals are still capped at 40fps: https://github.com/GNOME/vte/blob/master/src/vte.cc#L10770 https://github.com/GNOME/vte/blob/master/src/vte.cc#L10770
- kzrdude 3y ago
  Christian Hergert, the dev in this story, has posted a patch for vte related to these experiments, here https://gitlab.gnome.org/GNOME/vte/-/issues/2553#note_1850156 https://gitlab.gnome.org/GNOME/vte/-/issues/2553#note_185015...
- Longhanks 3y ago
  Well, it fits in with the bunch of folks that deem system tray icons, application theming, fractional scaling or window title bars unnecessary to arbitrarily limit their terminal's performance, while the competition has no such penalty.
  - audidude 3y ago
    It sounds like you're pretty biased, and that's fine. You do you. But I'm pretty sure that code pre-dates reliable access to vertical sync from applications. Either via XProperty notifications from the compositor, XPRESENT, or actual glSwapBuffers() and/or equiavalents.
- audidude 3y ago
  First we make it fast. Then we remove the FPS restriction. I would be very surprised if I don't manage to nuke that as part of this work.
posix86 3y ago
I once played a esoteric video game where you had to interact with a terminal inside a 3d world as part of the gameplay mechanic. It was implemented in unity, and it featured motion blur when a lot of output was generated. Since then I always wonder if text editors and terminals could actually greatly benefit from motion blur whenever text is moving. The purpose of motion blur is first to make things seems smoother, but mostly to indicate how things are moving on the screen with lower framerates. I think with motion blur you could make text jump way further frame by frame while understanding how text was moving. If you have a word that is bold on screen, you could make it jump half a screen with within a single frame while immediately understanding where it went. Wouldn't that help navigating e.g. huge logs (esp. if they're colored) faster while still having a sense of how far you moved frame by frame? If your terminal outputs so much that nothing of the screen is the same frame by frame, you could also still get a feeling of how much is actually outputted, by how blurry the screen is. Never got around implementing it though, curious what you think!
- Woshiwuja 3y ago
  I turn off motion blur in every game, would hate it on the terminal lol
- CaptainFever 3y ago
  Could you be talking about Event[0] by any chance?
- mrob 3y ago
  Motion blur can help compensate for low framerates if it's (approximately) physically accurate, i.e. temporally oversampled. This is how 24fps movies can look tolerable despite the ultra-low framerate: each frame provides more information about how the contents are moving than just a single unfiltered sample, because you can follow the motion blur trails. This is complicated by computer graphics being gamma corrected. If you average multiple temporal samples together in sRGB colorspace, brightness will vary unrealistically with motion speed. You need to calculate the motion blur in linear colorspace then convert to gamma colorspace before displaying it. And for best results, the image to be blurred should be HDR, with the blurred version mapped to the lower dynamic range of the screen. This best replicates in-camera motion blur, giving you clear trails behind bright points. However, any deliberately introduced motion blur is inferior to just increasing framerate. Your eyes already provide motion blur. Anything added by simulation or camera is unrealistic additional motion blur on top of this.
Piraty 3y ago
here's a good read about terminal emulators, including speed benchmarks and discussing security aspects: https://lwn.net/Articles/749992/ https://lwn.net/Articles/749992/ https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/
chenxiaolong 3y ago
Happy to see more folks working on fast terminal emulators! Earlier this year, I went through every single terminal emulator in Arch's repos and tested using them while compiling AOSP (Android). AOSP's Soong build system does not produce a lot of scrollback, but it does overwrite a line containing the progress ~150k times (once per source file). Alacritty was the only one that was both responsive and didn't eat up a CPU core (staying under 10%). Wezterm, Kitty, Foot, and Konsole stayed responsive, but used 100% CPU on a single core, causing a measurable impact to the build speed (though Konsole 23.08 seems to have regressed and now sometimes locks up). Most of the others became unresponsive or had multiple second delays trying to do anything (eg. ^C, opening new tab, etc.).
- audidude 3y ago
  What I was trying to show, and also why I have no interest in creating something out of Termkit, is just that we have a lot of low hanging fruit that can still be fixed. I'd rather do that work as part of VTE so all the applications I use benefit (including GNOME Builder, which I wrote and maintain). This was a fairly straightforward implementation of VT parsing and uses the retained render tree in GTK properly. There is no need to sacrifice CPU for GPU or vice-versa. You can literally do better in both directions while rendering at full frame rates.
qwerty456127 3y ago
Why care about terminal emulators speed? I never cared about anything (let alone terminals) to go above 30 fps. I've heard extra FPS can help in professional gaming but I can't even imagine a case when speed of any existing terminal emulator would be not enough (for what?). Surely its nice to make any app as efficient and responsive as physically possible (as long as this doesn't harm anything) but I still feel curious about what, besides pure perfectionism and competition, actually motivates people in this case.
- ihattendorf 3y ago
  I recently upgraded from 60 Hz to 160 Hz monitors and just regular mouse movement/scrolling/etc. is so much smoother. Is it necessary? No, but I won't willingly go back to 60 Hz, let alone 30 Hz.
  - piyh 3y ago
    30 hz 4k with shitty USB-C dongles is a terrible experience
    - fbdab103 3y ago
      Exactly my work setup at the moment. Amazing how quickly my excitement at the new 4k monitor was quelled.
  - andrewstuart2 3y ago
    I've done the same and was pretty dead set on it a while for gaming. And then I got a steam deck which can sometimes dip into the 30s or even 20s and I realized that it does feel jankier but it's definitely an acceptable trade off for something like the mobility of a deck. I'll even crank up graphics on my gaming desktop sometimes now just for eye candy even though it runs closer to 30-45fps.
    - strken 3y ago
      High stable fps is important for multiplayer shooters, and presumably other multiplayer or difficult genres where smoothly tracking objects with your mouse is part of the core gameplay. Every time I upgrade my desktop I notice measurably higher stats.
snvzz 3y ago
I favor kitty[0] and zutty[1]. Gnome terminal / libvte is and has always been slow, and alacritty might have good throughput, but sadly is high latency. 0. https://sw.kovidgoyal.net/kitty/ https://sw.kovidgoyal.net/kitty/ 1. https://tomscii.sig7.se/zutty/ https://tomscii.sig7.se/zutty/
zh3 3y ago
Back in the day, terminal emulators were fast enough that they were up to date by the time each 50Hz/60Hz period came around - why on earth are they now so much slower? A couple of days ago I spent a while trying to figure out why a piece of hardware appeared to be outputting serial data in bursts. After eliminating issues with the underlying hardware and buffering in the USB stack, it (too slowly) dawned on me that the issue was entirely due to how slow terminal emulators have become (this was on a fastish PC). Updating a screenful of text at 60/120Hz, why/how is it so much slower these days? (and what benefits have we gained in return for the slowdown?).
andoma 3y ago
Honestly, all I ask from a terminal emulator is to have a slick and fast search UX (similar to item on macOS)
NikkiA 3y ago
I've tried every "accelerated" terminal app that I see, yet I find I never perceive any improvement in response, only the negative effect of losing the helper UI of menus and such compared to my (now ~10 year usage) usual term of Sakura. Kitty came closest to being usable for me, but still it involved throwing away ease of access to various things to have a boost to performance that was only something I was told I was getting, not something I was experiencing.
da39a3ee 3y ago
> "Just going to put it out there because I don't intend to do anything with it, but I have created a terminal emulator that is twice as fast as the closest GPU-based renderer I've found (at least on Linux) which was Alacritty." > "I don't care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one." These sentences sounds conceited and arrogant.
- Woshiwuja 3y ago
  "If you cant do it you are trash" vibes
deafpolygon 3y ago
Just look at Windows Terminal - which is pretty damn fast.

Fast is good but given that any terminal is fast enough to type commands and scroll around, convenient is even better. Example: I went with tilix months ago and eventually switched back to Gnome terminal because tilix froze sometimes. Furthermore tilix doesn't have a way to bind commands to a profile to run them when opening a terminal with that profile. The freeze is of course 99% of my switching back.

throwaway02y 3y ago
Never experienced any freezes with tilix and I use it daily for years now. It's abandonware though.
- audidude 3y ago
  It's still GTK 3 using VTE and so doing the drawing with Cairo. It (VTE) has a lot of optimizations that made sense when we didn't have working GPU drivers. But for GTK 4, we can do things much differently and faster.

whalesalad 3y ago

alacritty is fast but kitty is faster. glad to see us racing to the top in this space.

tmtvl 3y ago
They're both leaving practical performance on the table by not implementing VT420 (or better) control sequences, though. So whatever gains you get from them are lost by applications needing to do more work. For example, tmux uses DECLRMM to restrict scrolling to the active part of horizontally split panes, and as neither Alacritty nor Kitty implements DECLRMM tmux will have to do more work to get the same effect. The author of Zutty has a writeup about it: https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-of-Zutty https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...
- deleted 3y ago
  [deleted]
- somat 3y ago
  as a contented xterm user, none of these "modern gpu accelerated terminals" really excited me. But the care shown in correct output by the author really grabbed my interest. I probably won't change, as I said I like xterm, but I am going to try it out.

CJefferson 3y ago

Looking at this, I’m reminded of early clang, which was often 5 or more times faster at compiling C++ than gcc, while handling maybe 95% of C++ code. While clang is still in my experience faster than gcc, it turns out handling that last 5% correctly can knock a lot off your performance. Of course with terminals it might turn out you don’t need that last 5%, or you really can get all the way and keep the speed, but this isn’t the first project dedicated to making “the fastest terminal”.

jchw 3y ago
The way I see it, modern terminal emulators are kind of like multimedia applications, they've got a frame budget. Today a lot of them don't necessarily spend that budget wisely. I think there is a legitimate point here. Compilers could be faster, but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. In my opinion, not so for terminals: I'm pretty sure you could analyze the amount of time spent rendering in a terminal emulator and come to the conclusion that a lot of it is essentially wasted, with exception of a few more modern terminal emulators that considered this more deeply. This is in part due to the nature of the outputs of terminal emulators vs compilers; like for high throughput, it would be good if the terminal emulator spent as little time as possible processing things that won't ever actually make it to a frame. Compilers are mostly not interactive though, and don't have the luxury of deciding to simply not do something because nobody is looking.
- db48x 3y ago
  > but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. I don’t think that there’s any evidence that this is true. In fact, the performance of the Rust compiler has continually improved over the last five years while _adding_ new features, and not by removing anything. <https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html> All a C++ compiler needs to do to get similar results is to have a team that does nothing but performance work, and is actually rewarded for it.
  - 3y ago

jchw 3y ago

Although people wonder why anyone cares about performance in terminal emulators, it's more about caring about inefficiency in terminal emulators. There are some legit cases where performance actually does come into play, like with high-throughput. Sometimes it's not even necessary, such as when terminal emulators do more work than they should processing data that won't be displayed; those things have the potential to impact the experience even when there is plenty of CPU and GPU to spare, like on a desktop machine. However, it's not just performance. It's also energy usage, particularly on small things like the Pinephone. Linux being an OS where the terminal is as powerful as it is, it's really good to see a high level of attention to detail going to terminal emulators finally. Terminal emulators should be extremely robust and extremely efficient; and finally, they're getting pretty close.

kgwxd 3y ago
I never really cared, but when I first dropped into a proper terminal in Ubuntu many years ago using ctrl+alt+n, or whatever the combo is, it really felt like the characters were appearing on the screen before I even touched the key. That’s when I learned emulators have a noticeable lag. I still don’t care much, but it sucks to know it’s there, no matter how much I spend on hardware.
- pmontra 3y ago
  Ctrl-Alt-F3 to console and Ctrl-Alt-F2 to go back to the GUI?
  - Izkata 3y ago
    Where the GUI is has changed over the years/by distro, so I use Ctrl+Alt+(right arrow) to cycle between them until I find it.
- mrob 3y ago
  xterm has no built in lag (your compositor will introduce some, but it's possible to disable compositing if you use Xorg). Kitty can be configured to have practically identical lag to xterm.

kzrdude 3y ago

It seems like he's not even sharing the code, which is unfortunate if Alacritty or others want to learn from this. I guess that's a personal choice, but is it in the spirit of fosstodon (the mastodon instance he's on.)?

audidude 3y ago
I already maintain two dozen GNOME projects. I wrote a huge amount of GTK's OpenGL renderer, the profiler we use on GNOME, GNOME Builder, and a huge amount of other parts of GNOME. I've even started to fix the library that people will actually use (VTE) instead of fragmenting communities with some other project. My commitment to "FOSS" is not up for debate. I've written in multiple places what it takes to get stuff that fast. If that isn't enough for any of those projects, I'm happy to take money in exchange for my time.

lylejantzi3rd 3y ago

This reminds me of the kerfuffle Casey Muratori caused last year when he dared suggest the windows terminal could be faster. https://twitter.com/cmuratori/status/1523024109831041024 https://twitter.com/cmuratori/status/1523024109831041024 https://github.com/cmuratori/refterm https://github.com/cmuratori/refterm

fbdab103 3y ago
I feel like you are really under-selling that entire drama. It started with Casey pointing out some slow terminal behavior[0], to which he received unreasonable flack, including this choice quote, >I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively… Casey then spent a weekend and produced a couple thousand line terminal emulator which seemed feature complete(? probably missing some bells and whistles), but blew away Windows performance. A year later, Microsoft released a patch, roughly incorporating some of Casey's suggestions, and did not credit him for anything[1]. Edit: This[2] seems to be the much bigger Hacker News discussion about the topic instead of [1]. If nothing else, [2] has a repeatedly edited post by the Microsoft author where attitudes are on full display. [0] https://github.com/microsoft/terminal/issues/10362 https://github.com/microsoft/terminal/issues/10362 [1] https://news.ycombinator.com/item?id=31372606 https://news.ycombinator.com/item?id=31372606 [2] https://news.ycombinator.com/item?id=31284419 https://news.ycombinator.com/item?id=31284419
- dundarious 3y ago
  To give a more complete story, they did belatedly credit him and others, in a later edit. Still a very poor showing from the relevant people at Microsoft.
- psd1 3y ago
  Wait, what? I read through that entire discussion. I do agree that the quote you pulled out was not ideal, but that's the only thing in there that's even remotely abrasive. Skyline in particular took great pains to provide context of why the performance issue was the way it was. Where's the flak, exactly? (FYI, no "c" in "flak")

sylware 3y ago

I may write my own but wayland, pure CPU rendering, assembly (x86_64/risc-v)... but... I am still on other projects.

mrob 3y ago

Meanwhile, all GNOME-based terminals are still capped at 40fps: https://github.com/GNOME/vte/blob/master/src/vte.cc#L10770 https://github.com/GNOME/vte/blob/master/src/vte.cc#L10770

kzrdude 3y ago
Christian Hergert, the dev in this story, has posted a patch for vte related to these experiments, here https://gitlab.gnome.org/GNOME/vte/-/issues/2553#note_1850156 https://gitlab.gnome.org/GNOME/vte/-/issues/2553#note_185015...
Longhanks 3y ago
Well, it fits in with the bunch of folks that deem system tray icons, application theming, fractional scaling or window title bars unnecessary to arbitrarily limit their terminal's performance, while the competition has no such penalty.
- audidude 3y ago
  It sounds like you're pretty biased, and that's fine. You do you. But I'm pretty sure that code pre-dates reliable access to vertical sync from applications. Either via XProperty notifications from the compositor, XPRESENT, or actual glSwapBuffers() and/or equiavalents.
audidude 3y ago
First we make it fast. Then we remove the FPS restriction. I would be very surprised if I don't manage to nuke that as part of this work.

posix86 3y ago

I once played a esoteric video game where you had to interact with a terminal inside a 3d world as part of the gameplay mechanic. It was implemented in unity, and it featured motion blur when a lot of output was generated. Since then I always wonder if text editors and terminals could actually greatly benefit from motion blur whenever text is moving. The purpose of motion blur is first to make things seems smoother, but mostly to indicate how things are moving on the screen with lower framerates. I think with motion blur you could make text jump way further frame by frame while understanding how text was moving. If you have a word that is bold on screen, you could make it jump half a screen with within a single frame while immediately understanding where it went. Wouldn't that help navigating e.g. huge logs (esp. if they're colored) faster while still having a sense of how far you moved frame by frame? If your terminal outputs so much that nothing of the screen is the same frame by frame, you could also still get a feeling of how much is actually outputted, by how blurry the screen is. Never got around implementing it though, curious what you think!

Woshiwuja 3y ago
I turn off motion blur in every game, would hate it on the terminal lol
CaptainFever 3y ago
Could you be talking about Event[0] by any chance?
mrob 3y ago
Motion blur can help compensate for low framerates if it's (approximately) physically accurate, i.e. temporally oversampled. This is how 24fps movies can look tolerable despite the ultra-low framerate: each frame provides more information about how the contents are moving than just a single unfiltered sample, because you can follow the motion blur trails. This is complicated by computer graphics being gamma corrected. If you average multiple temporal samples together in sRGB colorspace, brightness will vary unrealistically with motion speed. You need to calculate the motion blur in linear colorspace then convert to gamma colorspace before displaying it. And for best results, the image to be blurred should be HDR, with the blurred version mapped to the lower dynamic range of the screen. This best replicates in-camera motion blur, giving you clear trails behind bright points. However, any deliberately introduced motion blur is inferior to just increasing framerate. Your eyes already provide motion blur. Anything added by simulation or camera is unrealistic additional motion blur on top of this.

Piraty 3y ago

here's a good read about terminal emulators, including speed benchmarks and discussing security aspects: https://lwn.net/Articles/749992/ https://lwn.net/Articles/749992/ https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/

chenxiaolong 3y ago

Happy to see more folks working on fast terminal emulators! Earlier this year, I went through every single terminal emulator in Arch's repos and tested using them while compiling AOSP (Android). AOSP's Soong build system does not produce a lot of scrollback, but it does overwrite a line containing the progress ~150k times (once per source file). Alacritty was the only one that was both responsive and didn't eat up a CPU core (staying under 10%). Wezterm, Kitty, Foot, and Konsole stayed responsive, but used 100% CPU on a single core, causing a measurable impact to the build speed (though Konsole 23.08 seems to have regressed and now sometimes locks up). Most of the others became unresponsive or had multiple second delays trying to do anything (eg. ^C, opening new tab, etc.).

audidude 3y ago
What I was trying to show, and also why I have no interest in creating something out of Termkit, is just that we have a lot of low hanging fruit that can still be fixed. I'd rather do that work as part of VTE so all the applications I use benefit (including GNOME Builder, which I wrote and maintain). This was a fairly straightforward implementation of VT parsing and uses the retained render tree in GTK properly. There is no need to sacrifice CPU for GPU or vice-versa. You can literally do better in both directions while rendering at full frame rates.

qwerty456127 3y ago

Why care about terminal emulators speed? I never cared about anything (let alone terminals) to go above 30 fps. I've heard extra FPS can help in professional gaming but I can't even imagine a case when speed of any existing terminal emulator would be not enough (for what?). Surely its nice to make any app as efficient and responsive as physically possible (as long as this doesn't harm anything) but I still feel curious about what, besides pure perfectionism and competition, actually motivates people in this case.

ihattendorf 3y ago
I recently upgraded from 60 Hz to 160 Hz monitors and just regular mouse movement/scrolling/etc. is so much smoother. Is it necessary? No, but I won't willingly go back to 60 Hz, let alone 30 Hz.
- piyh 3y ago
  30 hz 4k with shitty USB-C dongles is a terrible experience
  - fbdab103 3y ago
    Exactly my work setup at the moment. Amazing how quickly my excitement at the new 4k monitor was quelled.
- andrewstuart2 3y ago
  I've done the same and was pretty dead set on it a while for gaming. And then I got a steam deck which can sometimes dip into the 30s or even 20s and I realized that it does feel jankier but it's definitely an acceptable trade off for something like the mobility of a deck. I'll even crank up graphics on my gaming desktop sometimes now just for eye candy even though it runs closer to 30-45fps.
  - strken 3y ago
    High stable fps is important for multiplayer shooters, and presumably other multiplayer or difficult genres where smoothly tracking objects with your mouse is part of the core gameplay. Every time I upgrade my desktop I notice measurably higher stats.

snvzz 3y ago

I favor kitty[0] and zutty[1]. Gnome terminal / libvte is and has always been slow, and alacritty might have good throughput, but sadly is high latency. 0. https://sw.kovidgoyal.net/kitty/ https://sw.kovidgoyal.net/kitty/ 1. https://tomscii.sig7.se/zutty/ https://tomscii.sig7.se/zutty/

zh3 3y ago

Back in the day, terminal emulators were fast enough that they were up to date by the time each 50Hz/60Hz period came around - why on earth are they now so much slower? A couple of days ago I spent a while trying to figure out why a piece of hardware appeared to be outputting serial data in bursts. After eliminating issues with the underlying hardware and buffering in the USB stack, it (too slowly) dawned on me that the issue was entirely due to how slow terminal emulators have become (this was on a fastish PC). Updating a screenful of text at 60/120Hz, why/how is it so much slower these days? (and what benefits have we gained in return for the slowdown?).

andoma 3y ago

Honestly, all I ask from a terminal emulator is to have a slick and fast search UX (similar to item on macOS)

NikkiA 3y ago

I've tried every "accelerated" terminal app that I see, yet I find I never perceive any improvement in response, only the negative effect of losing the helper UI of menus and such compared to my (now ~10 year usage) usual term of Sakura. Kitty came closest to being usable for me, but still it involved throwing away ease of access to various things to have a boost to performance that was only something I was told I was getting, not something I was experiencing.

da39a3ee 3y ago

> "Just going to put it out there because I don't intend to do anything with it, but I have created a terminal emulator that is twice as fast as the closest GPU-based renderer I've found (at least on Linux) which was Alacritty." > "I don't care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one." These sentences sounds conceited and arrogant.

Woshiwuja 3y ago
"If you cant do it you are trash" vibes

deafpolygon 3y ago

Just look at Windows Terminal - which is pretty damn fast.