21–30 of 128 posts
I replaced iTerm with Wezterm 6 months back. It feels lot more lighter and faster. As SRE I need to work a lot on terminal. I tried Alacritty for a while but Alacritty not supporting horizontal and vertical splits was a major setback for me.
Serious question: how much does it benefit to accelerate terminal on GPU? Is it really worth the effort?
Earlier quoted context omitted.
I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?
A really basic test is just type "base64 (ofc the differences might not be something you ever notice or care about)
I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
Earlier quoted context omitted.
A really basic test is just type "base64 (ofc the differences might not be something you ever notice or care about)
e.g. for me on Windows 11, Wezterm updates slower than both cmd.exe and Windows Terminal. It feels like about 300-400ms to give me control back when I hit ctrl+C. Windows Terminal must be about 100-200ms, cmd.exe maybe a tiny bit slower. I'm not sure speed benchmarks mean much for terminals though, there's going to be a lot of personal preference involved.
Tho control character latency likely doesn’t have anything to do with the responsiveness that GPU text rendering provides, since ctrl+c is a sequence captured by the OS it’s more likely to have something to do with which ever API the terminal uses to capture input or even the OS itself since I guess the OS still captures the sequence first then has some checks if the object can be universally copied and if not passes the sequence to the active window in focus for it to handle that.
I use https://codeberg.org/dnkl/foot
This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.
Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my com…
Serious question: how much does it benefit to accelerate terminal on GPU? Is it really worth the effort?
I had to stop using windows terminal because it has GPU acceleration, which ate up GPU memory I needed for pytorch/GPU accelerated neural nets. When doing regular development work, it’s another story.
This is an honest question. What is the advantage of GPU acceleration for a terminal emulator? I don’t do much low level graphics stuff, but a terminal seems fairly simple graphically, you are just drawing glyphs at xy cords. Would love it if someone had a good explanation. Obviously there are some terminal applications that could be redrawing very quickly, but that seems like a solved problem.
Is it more complicated than wanting to update the display as often as its fresh frequency? Faster screen updates, lower CPU & power usage. You might not notice the difference until you accidentally unleash a lot of output at once - then you'll see the difference. Some terminals start to update infrequently to save themselves, some hang completely while burning the CPU. Psychologically I feel more in control of my com…
The only time this happens, is when I do something wrong, like `cat`-ing the 12MB binary instead of the config.json, or `tail -f` into the output device of the core logging endpoint and forget to pipe into `grep`.
If that happens, I usually terminate the process anyway.
Earlier quoted context omitted.
I believe that there is a difference. I would just love to understand it better. Does anyone have a benchmark of the differences? Is it like a 2-3x improvement or only much smaller? What is the actual latency? Does anyone have any links to a low level explanation?
A really basic test is just type "base64 (ofc the differences might not be something you ever notice or care about)
When do I actually need to DISPLAY megabytes worth of output as lag-free as possible on a terminal?
There is no way for the intended recipient of displayed information (aka. the user) to process any of it, so what's the point of eliminating lag?
https://wezfurlong.org/wezterm/config/keys.html Happy to see that it includes support for clearing scroll back and that the default key binding for that is the same as it is in the Terminal.app that comes with macOS; Super + K. I just might give this Wezterm a go on my own computers. And since Wezterm is cross platform with support for all three computer platforms that I use; macOS, Linux, FreeBSD, I may finally have…
My configuration for Wezterm at the moment:
- I set the color scheme to Afterglow, which is a lot like the default color scheme of Terminal.app.
- I downloaded the SF Mono font from https://developer.apple.com/fonts/ so that it is available to Wezterm, and I defined the font size to be the one that I prefer. This is the font that Terminal.app uses by default but I guess in Terminal.app this font is actually bundled inside of the application because the font did not show up in Font Book and Wezterm couldn't find it either until I downloaded it from said link and installed it even though Terminal.app is already using it.
- I configured Command + K to clear not just scrollback (Wezterm default), but to also clear the viewport like Terminal.app does.
- I turned off tabs.
The are only a few things at the moment that I dislike about Wezterm:
1. The title of each window is simply "Wezterm", and tabs provide additional info but since I am not using tabs and the windows still are titled just "Wezterm" I am missing having the title of the Window be set to things like the current working directory and the currently running commands the way that Terminal.app does.
2. https://wezfurlong.org/wezterm/faq.html says that WezTerm version 20200620-160318-e00b076c and newer will automatically set $LANG appropriately on macOS, but I am using version 20211205-192649-672c1cc1 installed from homebrew on macOS Monterey 12.0.1, and it is not setting $LANG for me.
3. I am unable to input characters like æ, ø, å the way that I usually do which is Option + ', Option + o, and Option + a respectively on macOS with the macOS input language set to US. I don't know if this is a consequence of $LANG not being set that I mentioned above or if it's due to the application perhaps not using the operating system provided input methods.
4. When I close the last window the application closes, which is counter to how most applications on macOS work by default, and counter to how Terminal.app works by default. I often close terminals including the last terminal and then later like to tab back to Terminal.app and open a new window. With Wezterm I have to relaunch the application before I can open a new window after I have closed the last window.
Is there a way to make the Wezterm application stay running on macOS when I close the last window?