iTerm2 has a new drawing engine that uses Metal 2(gitlab.com)
gitlab.com
iTerm2 has a new drawing engine that uses Metal 2
https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer
264 comments
It's a funny feeling opening hacker news and seeing your project at the top :)
In iTerm2's case it's because of bad decisions about a decade ago. The data model is read & written on the main thread. The main thread is solely responsible for drawing operations if you use the standard drawRect: interface on NSView. That means that a slow draw blocks it from processing more data. Other work, like reading from the socket and parsing bytes into tokens was offloaded onto other threads years ago. Unwinding all the assumptions about single-threadedness is nearly impossible. The only way to reduce the main thread's workload is to use a GPU renderer because building the data structures the GPU needs can be done off the main thread after a quick copy of the necessary state.
In iTerm2's case it's because of bad decisions about a decade ago. The data model is read & written on the main thread. The main thread is solely responsible for drawing operations if you use the standard drawRect: interface on NSView. That means that a slow draw blocks it from processing more data. Other work, like reading from the socket and parsing bytes into tokens was offloaded onto other threads years ago. Unwinding all the assumptions about single-threadedness is nearly impossible. The only way to reduce the main thread's workload is to use a GPU renderer because building the data structures the GPU needs can be done off the main thread after a quick copy of the necessary state.
Thanks for iTerm2. I've been using iTerm since 2006-ish and iTerm2 since approximately whenever it came out (2011-ish?) :)
Apple's sorry hardware situation recently pushed me to move to Linux on a ThinkPad for most of my daily use, so I don't use iTerm2 as much now as I used to. (And, naturally, just after the return period on my ThinkPad expired, Apple rolled out a MBP with 32GB RAM X()
Your software made my life better every day for years. It was the first program I downloaded and installed after LittleSnitch when I set up a new Mac. Thank you.
Apple's sorry hardware situation recently pushed me to move to Linux on a ThinkPad for most of my daily use, so I don't use iTerm2 as much now as I used to. (And, naturally, just after the return period on my ThinkPad expired, Apple rolled out a MBP with 32GB RAM X()
Your software made my life better every day for years. It was the first program I downloaded and installed after LittleSnitch when I set up a new Mac. Thank you.
Just want to add my thanks for iTerm2. Having an IRL Quake-style console at work just makes me feel like a kid all day long even though I'm not messing around anymore but doing real work. :-P
Somewhat unrelated to the topic, but why did you decide to host source code on GitHub, but project issues and feature suggestions on GitLab?
Hey, happy user here -- thanks for doing iTerm2!
Thanks a lot for iTerm2.
BTW, I'd love to help to add overline support. Mind if I open an issue and ask for some pointers?
BTW, I'd love to help to add overline support. Mind if I open an issue and ask for some pointers?
File an issue! There are only a few bits left for style so they have to be used judiciously. Or come up with a better scheme for storing character attributes.
Really dumb question here: how can I map cmd+ctrl+w to “close other tabs”? It’s the default in Terminal.app, but I just installed iTerm2 a day ago and havent found an option in the settings for it.
Just did it :-)
https://gitlab.com/gnachman/iterm2/issues/6901
https://gitlab.com/gnachman/iterm2/issues/6901
Yes, thank you! Perhaps this has been asked before, but is there any hope of an Ubuntu port?
Only if openstep catches up with Apple, or I retire. I wouldn’t hold my breath.
Haha, ok. Thank you again for all your hard work! Iterm2 is 90% the reason I pay a premium for a Mac. I would gladly skip paying the apple tax and put the funds toward iterm2 on other platforms if it ever becomes available :)
Try yakuake, if you haven't.
Appreciate the insights here - and also the pragmatic approach!
Thanks much for iTerm 2 :)
Thanks for iTerm2!
> Like in a video game, the world moves at the same rate regardless of the frame rate
If only this were true. There are plenty of games where the frame rate is capped at 60hz because the physics engine is coupled to it. If you force a framerate increase via .ini tweaks or something, you get really weird physics. I think Skyrim had this problem. Also, there are examples of where changing the network tick rate [1] can affect the physics engines.
[1] https://www.youtube.com/watch?v=sB5u96Vgyks
If only this were true. There are plenty of games where the frame rate is capped at 60hz because the physics engine is coupled to it. If you force a framerate increase via .ini tweaks or something, you get really weird physics. I think Skyrim had this problem. Also, there are examples of where changing the network tick rate [1] can affect the physics engines.
[1] https://www.youtube.com/watch?v=sB5u96Vgyks
I found this[0] discussion on Jonathon Blow's youtube channel about game physics/framerate dependence. It certainly seems to more than simply a problem of software architecture as some commenters appear to suggesting here.
[0] https://www.youtube.com/watch?v=fdAOPHgW7qM
[0] https://www.youtube.com/watch?v=fdAOPHgW7qM
What happens if your computer can't support a 60 Hz frame rate?
The games slow down. Until recently, most Japanese games were tightly tied to 30hz or 60hz logic, and would speed up or slow down if forced (willfully or not) to run at different frequency. This is not strictly a Japanese games phenomenon, but I've seen it mostly in PC ports of Japanese developed games for consoles.
To me, that's bad software design. 40 years ago, developers used to sync their logic to the refresh cycles of the target machine's display. That's amazing, but also something that should not happen in 2018 (or 2010 or 1998).
To me, that's bad software design. 40 years ago, developers used to sync their logic to the refresh cycles of the target machine's display. That's amazing, but also something that should not happen in 2018 (or 2010 or 1998).
Isn't that the reason for the Turbo button?
For the younglings: it was a physical button to underclock the CPU on old PCs.
https://en.m.wikipedia.org/wiki/Turbo_button
For the younglings: it was a physical button to underclock the CPU on old PCs.
https://en.m.wikipedia.org/wiki/Turbo_button
Yes, but the turbo button is and should remain a relic of the past, rather than a cornerstone of modern gaming design.
Eh, it’s extremely difficult to write a physics engine that behaves predictably with variable timesteps. Likely impossible at the extremes.
The framerate of the physics simulation can be decoupled from the frame rate of the rendering loop. For example, you can aim for a 30fps steady timestep simulation and a vsync-capped rendering. you can then use interpolation methods for quick-and-dirty calculation to smooth the movement to match the rendering timestep.
My ignorance on this subject is a vast abyss, but reality seems to work OK with this, because "subjective" and "objective" time can be decoupled. The world doesn't really care if your video camera takes a snapshot every 1/30th or 1/60th of a second, it'll keep doing whatever it is doing at its own pace.
Can't a virtual world be built with the same principles?
Can't a virtual world be built with the same principles?
They can and they are. Take for example Forza Motorsport, the physics engine, i.e. How the cars react to different road conditions updates at 360 hz while the graphics updates at 60 hz.
May be real world is simulated with 5.39e44 fps, so you won't feel the difference between 30 fps or 60 fps camera. You can't simulate virtual world with similar performance yet.
No it isn't. You might need to set a minimum time step to avoid instability but a variable time step is trivial.
The only place it might cause issues is if you need it to be deterministic, e.g. for multiplayer.
The only place it might cause issues is if you need it to be deterministic, e.g. for multiplayer.
I read that comment and initially had the same response as you. But on re-reading it is good advice, and one shouldn't focus on edge cases in language, when IRL we would probably all be in furious agreement.
Obviously for most models it is simple to adapt to variable simulation periods without instability, either by microstepping (which commonly occurs anyway because the natural simulation freq is much faster than 60Hz), or because the process is just solving a stable DE or doing basic physics over a different period.
For debugging it is often much easier to run physics at a fixed rate. You do get different results at different rates due to numerical precision issues and error accumulation.
Obviously for most models it is simple to adapt to variable simulation periods without instability, either by microstepping (which commonly occurs anyway because the natural simulation freq is much faster than 60Hz), or because the process is just solving a stable DE or doing basic physics over a different period.
For debugging it is often much easier to run physics at a fixed rate. You do get different results at different rates due to numerical precision issues and error accumulation.
[deleted]
Unless the programmer specifically decouples graphics from the rest of the program, anything that renders to the screen will have to wait for that command to finish drawing. It will effectively govern the throughput of any program that both prints lots of text to screen and is not appropriately multithreaded.
Evan knows that. His question is why isn't it normal for the graphics to be explicitly decoupled in terminal emulators that care about draw performance.
Wrong. Splitting logic into separate threads is not necessary. In order to make the engine independent from FPS, you have to decide, how to handle excess/missing output. You can buffer, transform, average or simply drop excess frames. Missing frames can be worked around by repeating previous frames or reducing effective resolution (often done with a bit of blur — hi, Nvidia!). In either case there are limits to what can be achieved with those workarounds — eventually you'd have to throttle the fastest producer (renderer, physics engine or player input). All of that can be done just fine without threads — using asynchronous programming (incidentally, this is why many advanced rendering APIs are asynchronous).
Most games can simply "drop frames", when renderer isn't up to speed with engine. The result is minor loss of visual fidelity, which usually isn't too bad, unless FPS are horribly low. Things are more tricky for terminals, because 1) they need to maintain scrollback history 2) their output is more blocky, so "dropping frames" leads to horribly-looking ASCII animations.
There are some terminals, that do start dropping output, when rendered can't keep up. Others (for example, xterm) do refuse to do that by default, because they assume, that underlying program may do better job at handling low framerate, than general-purpose terminal emulator.
Either way, if you want to achieve fluid, visually pleasing rendering, you renderer should be as fast as possible.
Most games can simply "drop frames", when renderer isn't up to speed with engine. The result is minor loss of visual fidelity, which usually isn't too bad, unless FPS are horribly low. Things are more tricky for terminals, because 1) they need to maintain scrollback history 2) their output is more blocky, so "dropping frames" leads to horribly-looking ASCII animations.
There are some terminals, that do start dropping output, when rendered can't keep up. Others (for example, xterm) do refuse to do that by default, because they assume, that underlying program may do better job at handling low framerate, than general-purpose terminal emulator.
Either way, if you want to achieve fluid, visually pleasing rendering, you renderer should be as fast as possible.
>Splitting logic into separate threads is not necessary.
Unless you're already using Vulkan/Metal your render thread will most certainly be lockstep with the GPU and that will block your CPU throughput.
You haven't described CPU/GPU independence at all. You're just talking about sacrificing the FPS for CPU perf.
Unless you're already using Vulkan/Metal your render thread will most certainly be lockstep with the GPU and that will block your CPU throughput.
You haven't described CPU/GPU independence at all. You're just talking about sacrificing the FPS for CPU perf.
I don't know why this one was downvoted. It is exactly right. You don't need threads, you just need your function that parses input to not try to write everything it sees to the screen (drop frames).
The IRC client XiRCON did that back in 90’s. Regardless how slow your machine is you always got the output instantly, albeit with less FPS.
[deleted]
Is that truly the case for games? I thought game logic was usually programmed against a clock, so that the game logic isn't dependent on running at some pre-determined frequency. However, is it typically the case that the number of ticks per second is independent of the render time?
Some games do it differently, but evmar's advice matches recommendations that I've seen for game engines[0].
[0] https://gafferongames.com/post/fix_your_timestep/
[0] https://gafferongames.com/post/fix_your_timestep/
Hmm well my guess is that for a lot of terminal apps they're expecting to draw directly to the screen without ever dropping a frame.
You could add a buffer but if you can't drop frames that will only smooth out vsync wait.
You could add a buffer but if you can't drop frames that will only smooth out vsync wait.
Nobody bothers to decouple them because usually rendering a terminal is trivial and the output rate isn’t as fast for most use cases. But it sounds like if you’ve done it before it might be a cool thing to contribute to your preferred open source terminal program (if you want to.)
That’s simply not true. A lot of terminals can’t output even ‘ls’ fast enough once colored output is enabled.
> But it sounds like if you’ve done it before it might be a cool thing to contribute to your preferred open source terminal program (if you want to.)
It’s not trivial to implement it in an existing codebase. Quoting from ITerm2’s Subpixel Antialiasing document:
> iTerm2’s design burdens the main thread with handling input from the TTY. A better design would perform only drawing and other UI activity on the main thread, but it’s too hard to change as there are thousands of implicit assumptions baked in to the code.
It’s not trivial to implement it in an existing codebase. Quoting from ITerm2’s Subpixel Antialiasing document:
> iTerm2’s design burdens the main thread with handling input from the TTY. A better design would perform only drawing and other UI activity on the main thread, but it’s too hard to change as there are thousands of implicit assumptions baked in to the code.
After trying out alacritty[1] and seeing just how good gpu-accelerated terminal could be I’ve been eagerly awaiting an update like this from iterm.
I really wish iterm was cross platform. I’ve realized when switching between Mac and Linux how important the terminal is to my development and quality of life.
1. https://github.com/jwilm/alacritty
I really wish iterm was cross platform. I’ve realized when switching between Mac and Linux how important the terminal is to my development and quality of life.
1. https://github.com/jwilm/alacritty
I would recommend kitty[1] as well, it certainly has more features than alacritty, like opening links via keyboard using hints.
1. https://github.com/kovidgoyal/kitty
1. https://github.com/kovidgoyal/kitty
I recommend Cool Retro Term. No tabs. Not a lot of features. Emulation can be a little strange. But it's cross-platform and a metric ass ton of fun.
https://github.com/Swordfish90/cool-retro-term
And if you push the settings right, you can use it to convince the procurement department that you need a new monitor.
https://github.com/Swordfish90/cool-retro-term
And if you push the settings right, you can use it to convince the procurement department that you need a new monitor.
Cool Retro Term is based on konsole, so it's actually a solid terminal emulater... and like you pointed out... loads of fun.
Just had a look at their docs:
https://sw.kovidgoyal.net/kitty/remote-control.html
Cool, it even works over SSH! Wait, what? This lets a remote server take over your workstation.
https://sw.kovidgoyal.net/kitty/remote-control.html
Cool, it even works over SSH! Wait, what? This lets a remote server take over your workstation.
...so don't enable that feature? It's off by default AFAICT.
I actually like alacritty, but surprisingly latency is still much higher than on xterm or eshell. These are relatively slow rendering massive amounts of text (eshell much slower than xterm, and lacking many features).
However, the feature I price the most is quick responsiveness when I type. For that, I still find xterm extremely good.
However, the feature I price the most is quick responsiveness when I type. For that, I still find xterm extremely good.
I am surprised to see nobody has posted a link to Dan Luu's article about benchmarking terminal emulator latency:
https://danluu.com/term-latency/
For me, one of the takeaways from this is that time taken to cat a large file is a poor benchmark of a terminal emulator.
This article also includes a nice demonstration of yet another application of Rust - as an easily reproducible and highly reliable way to load your machine so hard it interferes with your terminal.
https://danluu.com/term-latency/
For me, one of the takeaways from this is that time taken to cat a large file is a poor benchmark of a terminal emulator.
This article also includes a nice demonstration of yet another application of Rust - as an easily reproducible and highly reliable way to load your machine so hard it interferes with your terminal.
Any low-level language can do that.
Any idea how it affects battery usage on a laptop with an integrated GPU?
iTerm actually disables the Metal rederer while on battery by default.
I think that was the point of their question. While it's disabled by default, if it goes from 12h life to 6h, people will leave disabled. If it goes from 12h to 11.5h, people maybe would consider flipping that toggle.
Kind of counter intuitive. Wouldn’t the GPU be more efficient at rendering graphics than the CPU? For laptop models with dedicated GPU just use the integrated one on battery but ALWAYS prefer Metal GPU rendering to software.
No, it's not. Each visible pane gets its own thread, and three frames are pipelined. That means you could easily keep two cores plus your GPU going full steam (provided you have an underpowered GPU, which you almost certainly do, because you have a mac). In the legacy renderer, everything happened on the main thread so the most power it could draw was one core at 100%.
> In the legacy renderer, everything happened on the main thread so the most power it could draw was one core at 100%.
We’re not talking about wattage, but energy consumption. I.e. a single core working at its max for 5 seconds uses more power than three cores working for one second. It’s a question of efficiency, not how many cores are working at once.
We’re not talking about wattage, but energy consumption. I.e. a single core working at its max for 5 seconds uses more power than three cores working for one second. It’s a question of efficiency, not how many cores are working at once.
I’m guessing here but given the target of macOS this is done to prevent the GPU from being used. Many apps on macOS can do their drawing on the CPU or via the onboard Intel graphics. Metal presumably would force the GPU on, which would impact battery life.
Has the bug been fixed where it doesn't disable? I had to track down why my Nvidia GPU was being used all the time and killing my battery. Turns out it's iTerm2 and it isn't disabling the renderer correctly.
"gpu-accelerated cross platform" is not that hard as it sounds.
Here is an example of GPU rendering with support of Acrylic(Windows) / Vibrancy (MacOS) so popular in terminal implementations: https://sciter.com/sciter-4-2-support-of-acrylic-theming/
Here is an example of GPU rendering with support of Acrylic(Windows) / Vibrancy (MacOS) so popular in terminal implementations: https://sciter.com/sciter-4-2-support-of-acrylic-theming/
Your link is about html themes? What does it have to do with cross platform, GPU accelerated drawing?
Sciter is an HTML rendering engine. It has to do its drawing somehow, and apparently it uses GPU acceleration across platforms.
alacritty is meant to be fast, but it isn’t even close yet. The last time I checked there were multiple issues open about it being in reality slower than even terminal.app
I tried this feature in the nightly version and kitty[1] and alacritty[2] still feel faster than iterm2.
1. https://github.com/kovidgoyal/kitty
2. https://github.com/jwilm/alacritty
1. https://github.com/kovidgoyal/kitty
2. https://github.com/jwilm/alacritty
iTerm2 was not designed for GPU rendering from day one so it suffers from some complexity that hurts performance. This will get better in macOS 10.14 because I won't have to worry about subpixel antialiasing which adds some extra steps (details here: https://docs.google.com/document/d/1vfBq6vg409Zky-IQ7ne-Yy7o...).
There's also a lot of preprocessing to do before sending work to the GPU. For example, computing the color of each cell is a very complex algorithm because foreground and background colors interact with each other and also determine the font. For example, you can enable thinner strokes only when it's light text on a dark background. Work can't be sent to the GPU until the text is rendered into a texture, which means colors must be known. There's room for optimization here for common cases, but I haven't taken that on yet. My goal for 3.2 is for it to be an improvement over the legacy renderer and a solid foundation for iteration in the future.
There's also a lot of preprocessing to do before sending work to the GPU. For example, computing the color of each cell is a very complex algorithm because foreground and background colors interact with each other and also determine the font. For example, you can enable thinner strokes only when it's light text on a dark background. Work can't be sent to the GPU until the text is rendered into a texture, which means colors must be known. There's room for optimization here for common cases, but I haven't taken that on yet. My goal for 3.2 is for it to be an improvement over the legacy renderer and a solid foundation for iteration in the future.
both of these projects need a 1080p youtube video on their homepages to show __WHY__ i need blazing fast GPU support for a terminal
Hehe Yeah that's what I did actually, granted I'm a heavy vim user and feel the difference very quickly while switching between files, scrolling, etc. But yeah I did in fact recorded video and saw the delta there. I'm sure for most people iterm2 is a more than enough choice.
I’m curious, as a non-terminal editor person, are there any other applications where you can see or feel the benefit?
It still seems to take a long time to cat a file in iTerm compared to Terminal.app.
In Terminal, I can cat a 1.5M line file in about 5 seconds, it takes about twice as long in the new iTerm beta.
But iTerm is certainly updating the screen more often than Terminal (it looks smoother at least), so maybe that's because Terminal is doing a better job of allowing the screen buffer to update independently of the drawing thread.
In Terminal, I can cat a 1.5M line file in about 5 seconds, it takes about twice as long in the new iTerm beta.
But iTerm is certainly updating the screen more often than Terminal (it looks smoother at least), so maybe that's because Terminal is doing a better job of allowing the screen buffer to update independently of the drawing thread.
Yes, Terminal does it more independently. Maybe some day I'll make enough on Patreon that I can quit my day job and fix that :). If this is really important to you there are knobs you can turn to trade off refresh rate vs throughput. Enable "Prefs>General>Advanced GPU Settings>Maximize Throughput" and then fiddle with "Prefs>Advanced>When adaptive framerate is enabled and using the Metal renderer, refresh at this rate during high throughput conditions (FPS)". Adaptive framerate works by estimating the current throughput and adjusting the refresh rate accordingly. Terminal.app does this very aggressively, dropping the frame rate to 10 FPS so it can cat the 1.5M file so quickly.
I noticed that on your Patreon, you have that you're creating "Software". To many people that's too vague, (despite the header). I noticed that concrete software titles do better, like "is creating Vue.js" instead of "Software" or "JavaScript libraries", or "Mastodon" instead of "Social Networking software" etc.
It's a minor thing, but may be something to consider.
It's a minor thing, but may be something to consider.
This might seem specious to some people but there have been at least two intervals in my career where I ran into bad benchmarks of our app, because the person doing the measurement was running it in the foreground on a subpar terminal where writing to console was the bottleneck.
Occasionally, but less frequently, you can run into a similar symptoms just running build scripts.
Occasionally, but less frequently, you can run into a similar symptoms just running build scripts.
I remember this from the SBCL docs:
"Important: It is highly recommended that you run the make.sh script in either a very fast terminal such as xterm (the GNOME terminal and the OS X terminal are too slow) or that you run it in a detached GNU screen session (use C-a d to detach the session and screen -r to resume it). The SBCL compile produces lots of output and your system's terminal program will likely slow down the compile in a drastic manner."
http://www.sbcl.org/getting.html
"Important: It is highly recommended that you run the make.sh script in either a very fast terminal such as xterm (the GNOME terminal and the OS X terminal are too slow) or that you run it in a detached GNU screen session (use C-a d to detach the session and screen -r to resume it). The SBCL compile produces lots of output and your system's terminal program will likely slow down the compile in a drastic manner."
http://www.sbcl.org/getting.html
OT: There's a related question on StackOverflow where the same program had different runtimes on different terminals.
https://stackoverflow.com/a/21947627
https://stackoverflow.com/a/21947627
Unrelated to the topic: are you the same guy who does the smash videos?
Nope!
I've had this handle since around 1998, but other people started grabbing it in other forums after that. I'm not the twitter ninkendo nor the steam ninkendo either.
I only have this handle without trailing numbers on here, Ars Technica's forums, and gmail. (Formerly reddit too, but I deleted my account there when the site became a bit too toxic.)
I've had this handle since around 1998, but other people started grabbing it in other forums after that. I'm not the twitter ninkendo nor the steam ninkendo either.
I only have this handle without trailing numbers on here, Ars Technica's forums, and gmail. (Formerly reddit too, but I deleted my account there when the site became a bit too toxic.)
Is there a way to know if you're actually using the GPU renderer? Because it seems like there are several reasons why it might not be used...
Per the article, you can enable the FPS monitor in Advanced Settings which only shows up when using the Metal renderer.
Click the link. That and much more is answered there.
Cool, I might give this a try and consider moving back to iTerm. I was using it previously but decided to go back to the default Terminal + Fish shell for better performance and not having to install an extra application.
Agreed on using standard terminal. I’d like if someone could explain what utility they get out of iTerm (or any other non-builtin terminal).
I’ve found the performance of iTerm in particular to be far inferior to builtin, especially when the buffer grows large. iTerm even has a fixed buffer size by default and still has worse performance.
Alacritty is supposed to be fast, but then doesn’t support any scrolling, has a poor window resizing flow, and doesn’t have tabs. The suggestion is to use tmux for all that, but then Alacritty+tmux is slower than builtin.
- “performance” above means smoothness of scrolling and general “perceived performance” type things. Haven’t actually tried any real tests.
I’ve found the performance of iTerm in particular to be far inferior to builtin, especially when the buffer grows large. iTerm even has a fixed buffer size by default and still has worse performance.
Alacritty is supposed to be fast, but then doesn’t support any scrolling, has a poor window resizing flow, and doesn’t have tabs. The suggestion is to use tmux for all that, but then Alacritty+tmux is slower than builtin.
- “performance” above means smoothness of scrolling and general “perceived performance” type things. Haven’t actually tried any real tests.
Some features I just can't live without:
* tmux integration. Whether I'm in a remote server or my own machine, just use -CC and I can now use tmux with the same keybindings I would use without tmux.
* Watch for the completion of a command. Especially useful if you happen to be using a language with a slow compiler like Haskell or Rust. Plays a nice ding when the command is done. (This may require shell integration).
* Even if you forgot to run your command with time, iTerm can still tell you the wall clock time of your command. (Shell integration too).
And then just small things that the builtin Terminal doesn't have:
* focus follows mouse * smart selection (for example it could detect a URL and you can select the whole URL, then command-click to open) * copy on select
* tmux integration. Whether I'm in a remote server or my own machine, just use -CC and I can now use tmux with the same keybindings I would use without tmux.
* Watch for the completion of a command. Especially useful if you happen to be using a language with a slow compiler like Haskell or Rust. Plays a nice ding when the command is done. (This may require shell integration).
* Even if you forgot to run your command with time, iTerm can still tell you the wall clock time of your command. (Shell integration too).
And then just small things that the builtin Terminal doesn't have:
* focus follows mouse * smart selection (for example it could detect a URL and you can select the whole URL, then command-click to open) * copy on select
Just wanted to note: focus follows mouse is possible with Terminal.app with
defaults write com.apple.Terminal FocusFollowsMouse -bool true
Regarding watching command completion, I built a tool for that purpose [1].
I use it mostly when working through SSH on the go and with slow connections.
[1] https://github.com/hoffa/pingu
I use it mostly when working through SSH on the go and with slow connections.
[1] https://github.com/hoffa/pingu
To be fair, the shell itself can tell you the wall clock time. I have fish doing that for me on Terminal.app.
My favorite feature of iterm2 is that it can detect borders and confine the selection within them (e.g. only selecting one side of a tmux or vim split). This means I don’t have to bother figuring out how to synchronize the clipboards of OS X and various terminal apps, for most use cases.
The main iterm features I use extensively are split panes, broadcasting, and profiles.
CMD+O brings up the profile switcher, type the tag I want and hit enter.
Profiles let you configure cwd, commands to run (virtualenv activation), theme colours, and a bunch of other things.
My “prod” profile ssh’s into a management box, sets the background to pink, and puts a “PROD” badge in the top right corner.
CMD+O brings up the profile switcher, type the tag I want and hit enter.
Profiles let you configure cwd, commands to run (virtualenv activation), theme colours, and a bunch of other things.
My “prod” profile ssh’s into a management box, sets the background to pink, and puts a “PROD” badge in the top right corner.
> Agreed on using standard terminal. I’d like if someone could explain what utility they get out of iTerm (or any other non-builtin terminal).
For me it's simply that I couldn't get custom colors (e.g., the Solarized Dark theme) to display correctly with built-in Terminal. I haven't tried in 5+ years though -- maybe it's fixed now, and/or maybe I was doing something wrong at the time. But iTerm "just worked", and I never noticed performance issues so once I switched I never looked back. shrug
For me it's simply that I couldn't get custom colors (e.g., the Solarized Dark theme) to display correctly with built-in Terminal. I haven't tried in 5+ years though -- maybe it's fixed now, and/or maybe I was doing something wrong at the time. But iTerm "just worked", and I never noticed performance issues so once I switched I never looked back. shrug
That is actually fixed now.
Seems macOS Terminal app still hasn't True Color support. Tried running https://github.com/tclamb/iTerm2/blob/d0ecb297727a59c9ee5511... both in Terminal app and iTerm 2, and only iTerm 2 shows all colors, whereas Terminal app still shows only some colors. My VIM themes also look more bleak in the default Terminal app.
Cool, thanks -- maybe I'll give built-in Terminal another whirl at some point then.
The ability to set a hotkey to toggle the terminal is a must. I assigned ± to it (i.e. pressing it will toggle the window).
>Alacritty is supposed to be fast, but then doesn’t support any scrolling, has a poor window resizing flow, and doesn’t have tabs. The suggestion is to use tmux for all that, but then Alacritty+tmux is slower than builtin.
Alacrity is just an experiment at the time.
Alacrity is just an experiment at the time.
The one feature I miss most in Terminal.app is smart selection and automatic copy on double-click.
For example, on double click the Terminal.app will select `path.txt` from `some/long/path.txt`. iTerm will select the whole thing and copy it to the clipboard.
For example, on double click the Terminal.app will select `path.txt` from `some/long/path.txt`. iTerm will select the whole thing and copy it to the clipboard.
I do too, kinda, but I use tmux to copy text from the terminal into the clipboard, and have for years. The muscle memory around that is so ingrained now that I only rarely found myself using iTerm’s smart selection.
It was nice, though.
It was nice, though.
For me it’s the split pane features. I know tmux and screen can do this, but I feel like it’s a better experience in iterm.
Things I love in iTerm include the following:
* cmd-click on URLs or filenames to open them in my browser resp. editor -- even recognizes "FILENAME:LINE" to jump to the right line in my editor, which is super useful for errors printed by a compiler
* changing the theme when using SSH and/or root, so I don't accidentally issue commands on the wrong machine or as root
* split views
* lots of other, often "small" features, which I can't think of right now but which I usually notice quickly if forced to use Terminal.app
for me the #1 thing is the non-standard full-screen behavior, which lets my hit cmd+return and instantly full-screen the window, without any animation or creating a second workspace.
You might be interested in spectacle. It's a light weight window manager for os x that will let you do that (and more) with any app.
https://www.spectacleapp.com/
https://www.spectacleapp.com/
I use spectacle extensively, that's why I enjoy iTerm' fullscreen feature so much :-)
Can't that be accomplished in any macOS terminal by redefining the application's keyboard shortcuts in System Preferences?
It's not about the shortcut, it's about the behavior. iTerm'a fullscreen behavior works fundamentally differently than the standard macOS fullscreen behavior (no animation, no dedicated space, etc). Much more like spectacle, but hiding the window chrome.
Using non-standard interface elements and methods is the #1 way to get me to stop using a macOS product. Your program has to be pretty darned special for me to learn a whole new set of muscle memory movements for it.
Heck, I about dumped OS X when Apple changed the default application opening method. It used to be that when an application was loading and you switched to another window, the application opened behind what you were now working on. Or if you were working on something and another application in the background opened a window, you only got the jumping icon to let you know.
Today, applications can hijack focus pretty much whenever they want, aping one of Windows' most annoying UI features.
Heck, I about dumped OS X when Apple changed the default application opening method. It used to be that when an application was loading and you switched to another window, the application opened behind what you were now working on. Or if you were working on something and another application in the background opened a window, you only got the jumping icon to let you know.
Today, applications can hijack focus pretty much whenever they want, aping one of Windows' most annoying UI features.
Don't worry, iTerm does native fullscreen by default.
To get this, you need to uncheck "Native Full-screen" in preferences
I keep being told I must use iTerm2 and I have been. But I haven’t found anything it does that is better than the built in Terminal app. I’m going back to Terminal unless I find some reason to stick with it.
Not everyone needs the features iTerm provides. I used to use Terminal for a long time, but now I use iTerm because it gives me nice things like shell integration and notifications when jobs finish.
My main reason is very simple, there is a setting to allow resizing the widow by pixel instead of but character, which means I can make the window fill all the available space on my desktop
[deleted]
In my case, iTerm2 can do more sophisticated keyboard remapping than the standard terminal. Specifically: I have Caps Lock globally remapped to Command. Except, in iTerm, it acts as Control. Except, if I'm using some specific combos, like Cmd-Tab or Cmd-`; then it acts as Command again.
Oh wow, great idea! Now that I'm working more often with linux, I kinda got Caps+C etc. in my muscle memory, because I set Caps as Ctrl. When I switch back to macOS, it takes a while of wondering why my shortcuts won't work.
Care to explain how exactly you set this up? I guess in System Preferences -> Keyboard you set Caps to Cmd. And then?
In iTerm Preferences, Keys, set Left Command to Control, then in the Key Mappings list, add each Cmd-xyz combo you want to preserve, and set its action to "Do Not Remap Modifiers".
I like Terminal, but a very specific feature of iTerm2 I wish Terminal had is using one of the option keys as meta, while letting you keep the other for typing characters like "@" on some non-english keyboards.
I’m a huge fan and every day user of tabs and split windows features in iTerm. Any performance hit for it for me has been negligible— save for one buggy update which was promptly fixed.
I use tmux coupled with that, btw.
I use tmux coupled with that, btw.
Alacritty are developing a scrolling feature. Should land soon ish.
I use iTerm simply because the standard emacs keybindings don't work in Terminal. I'm sure there's some configuration somewhere that can fix that. But iTerm is properly configured out of box.
Do you mean the readline bindings (in bash shell) or do you mean when you run emacs?
I usually enable the readline style keybindings system wide (move character forward/backward, move word forward/backward) using a custom DefaultKeyBinding.dict — but then typically have to figure out workarounds for programmer type applications which try to resupply these shortcuts expecting the keys to be bound to random Unicode characters rather than already rebound to the actions ... as I recall — with my customization the keybindings don’t work by default in iterm2 and I had to go in and change something to get the correct behavior (fortunately there is an option). Many programmery type applications have the same issue (fortunately it’s mkstly possible to customize them all).
So it’s stjll possible to get the emacs keybindings at all text inswertion points systemwide — but it’s a hassle... In the glory days of OS X — pre 10.5, none of this was necessary — option-f option-b etc were just bound to the right thing by default rather than printing pointless Unicode characters ... I’m still annoyed by that change and by the fact that a bunch of complicated configurations are required to get the right behavior nowadays ...
I usually enable the readline style keybindings system wide (move character forward/backward, move word forward/backward) using a custom DefaultKeyBinding.dict — but then typically have to figure out workarounds for programmer type applications which try to resupply these shortcuts expecting the keys to be bound to random Unicode characters rather than already rebound to the actions ... as I recall — with my customization the keybindings don’t work by default in iterm2 and I had to go in and change something to get the correct behavior (fortunately there is an option). Many programmery type applications have the same issue (fortunately it’s mkstly possible to customize them all).
So it’s stjll possible to get the emacs keybindings at all text inswertion points systemwide — but it’s a hassle... In the glory days of OS X — pre 10.5, none of this was necessary — option-f option-b etc were just bound to the right thing by default rather than printing pointless Unicode characters ... I’m still annoyed by that change and by the fact that a bunch of complicated configurations are required to get the right behavior nowadays ...
I mean the readline bindings in the shell, but I just launched terminal to see which ones don't work, and they all appear to work now. So maybe that's been fixed. That's great it if works. I don't use any of iTerm's bells and whistles.
If you meant Meta keys doesn't work in Terminal.app, then the option is in Preferences → Profiles → (Choose your profile) → Keyboard → [/] Use Option as Meta key
I switched from iTerm to Terminal about a year ago, since I am using tmux for multiplexing and emacs for file management with magit.
I don't really miss any iTerm features. Have to look up what's new!
I don't really miss any iTerm features. Have to look up what's new!
I use iTerm 2 daily. What are y'all doing in your terminals that this kind of thing would matter at all or even be perceptible?
If you maximize on a 4K monitor and use tmux on a remote server there is a pretty significant amount of latency. I never noticed until I tried alacritty, the difference is astonishing.
That being said, iTerm2 is plenty fast enough for my purposes as it is today.
That being said, iTerm2 is plenty fast enough for my purposes as it is today.
Dwarf fortress.
VIM, and overall just being fast. It is extremely perceptible, especially if you ever use something like Arch Linux + st (or one of the faster terminals). iTerm is slow as shit compared to that.
Memory consumption and cpu usage will go down noticeably. If you have 20 tabs open it can add up.
Scrolling.
One thing I've never been able to get iTerm to do that every other iTerm user seems to have setup almost automatically is how it ghosts the full completion of a command you are typing (faded behind your live typing), presumably from your history, and then you can just tab to complete the whole thing. So many commands are repeated often and I've never been able to get mine to do this very basic feature.
You are probably referring to fish shell which has this feature (https://fishshell.com/).
However, I find that zsh + ohmyzsh works just as well. After typing the beginning of a command you can use the arrow keys to cycle through all commands in the history with the same beginning.
A third method for efficient history search is ctrl+r. Just press ctr+r and start typing part of the command. Then you press enter to execute or ctr+r to cycle through the history.
However, I find that zsh + ohmyzsh works just as well. After typing the beginning of a command you can use the arrow keys to cycle through all commands in the history with the same beginning.
A third method for efficient history search is ctrl+r. Just press ctr+r and start typing part of the command. Then you press enter to execute or ctr+r to cycle through the history.
fish is nice but I've ran into too many issues where some weird shell command / script I find online is expecting to be in bash and I have to switch out of fish, so its hard for me to switch.
As long as they don't need to be sourced, you can just add a shebang for bash at the top of the scripts and run them via bash.
If they do need to be sourced, you can use bass: https://github.com/edc/bass
Wow this is neat — I’m gonna try this out. Does it really work?
It works at least for nvm (caveat: Installed from nvm directly, not homebrew), and my company's ssh setup script, which are the two reasons I've had cause to use it.
Just run it with bash then. The syntax is too different to run bash script on fish.
You can usually drop to a bash subshell for those
Fish 3 will fix a lot of that. Try the nightly builds.
oh-my-zsh is effectively unmaintained. That is not the worst thing in the world, but one may wish to consider prezto as an alternative:
https://github.com/sorin-ionescu/prezto
https://github.com/sorin-ionescu/prezto
I see like 6 commits to oh-my-zsh in the past week. Why do you say its not maintained?
688 open pull requests, the existence of a half-dozen competing projects, and Robby's blog post suggesting that he doesn't take the project seriously.
Or zplug which allows you to load oh-my-zsh scripts as well.
ctr+r is a great tip!
It's worth getting used to your new discovery a bit first (C-r is isearch-backward), partly because it's useful in other places, too – for example ipython or any decent programming language shell has emacs-derived keybindings including isearch via readline or a clone.
But after that, I'd suggest giving fzf (https://github.com/junegunn/fzf) a try.
But after that, I'd suggest giving fzf (https://github.com/junegunn/fzf) a try.
Using integrated fzf is so much better than cycling through one by one.
Zsh also has history completion of words.
M-/ (opt/alt + /)
M-/ (opt/alt + /)
You're talking about autosuggestion, one of my ABSOLUTE FAVORITE features. I tell everyone about this:
If you're nervous about running shell commands here they're the same as the installation on the site if you care to check:
Combine this with using control+p to cycle through previous commands means you can be a wizard at commands quickly
If you're nervous about running shell commands here they're the same as the installation on the site if you care to check:
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
git clone https://github.com/zsh-users/zsh-autosuggestions $ZSH_CUSTOM/plugins/zsh-autosuggestions
# Plugins
plugins=(zsh-autosuggestions)
Combine this with using control+p to cycle through previous commands means you can be a wizard at commands quickly
I thought that was a zsh thing rather than an iTerm2 thing. You can use zsh in iTerm2 though.
Hm, that must mean everyone I know is using zsh and I didn't realize that... that strongly suggests I should use it too!
Specifically, most people use oh-my-zsh, which is a preconfigured set of zsh plugins and various other settings[1] with the autosuggestions[2] plugin.
1 - https://github.com/robbyrussell/oh-my-zsh
2 - https://github.com/zsh-users/zsh-autosuggestions
1 - https://github.com/robbyrussell/oh-my-zsh
2 - https://github.com/zsh-users/zsh-autosuggestions
oh-my-zsh has more than six hundred open pull requests, and can be considered unmaintained. It is perfectly usable in most respects, and I would not expect that to change in the near future. However, some competing projects have started because of that, and may be worth consideration.
https://github.com/sorin-ionescu/prezto https://github.com/zsh-users/antigen See also: https://github.com/unixorn/awesome-zsh-plugins
https://github.com/sorin-ionescu/prezto https://github.com/zsh-users/antigen See also: https://github.com/unixorn/awesome-zsh-plugins
Zsh and fish are, imo, much better environments than bash. And bash, once tamed, due to its ubiquity, is a better choice for scripting.
People should realize terminal and scripting don't need to be done using same shell.
I use fish for scripting but run zsh for terminal. (fish had couple weirdness in day to day terminal use and zsh could do pretty much all fish could do with zplug.)
I use fish for scripting but run zsh for terminal. (fish had couple weirdness in day to day terminal use and zsh could do pretty much all fish could do with zplug.)
not my choice. certainly less people suffer bash in the BSD world.
while bashims may give additional features, readability and portability suffers. I much prefer scripts using a posixish #!/bin/sh and a strict subset of shell syntax. something like pdfx.
while bashims may give additional features, readability and portability suffers. I much prefer scripts using a posixish #!/bin/sh and a strict subset of shell syntax. something like pdfx.
That's why I emphasized "choice", using sh for scripting is a valid choice.
You can do this in Zsh: https://github.com/zsh-users/zsh-autosuggestions
You can get that if you are using fish shell. For zsh, there is an auto suggestion package that you have to install.
This is great! One question: when would you need 60 FPS in a terminal? What CLIs or usages does this make a difference for?
It’s easier on your eyes to follow and just looks aesthetically better also.
Is it? Playing around with the Metal renderer and FPS monitor, I rarely go above 30fps in day-to-day work, and most of the time I'm hitting 10-15fps. There's only certain use cases where you'll actually reach 60fps.
I get 60 FPS when scrolling.
Even when scrolling, I rarely hit 60. Most of the time, I'm staying in the 40 range and hit 60 for one or two frames.
The FPS meter only works with the Metal renderer, so I can't directly compare it and the CPU renderer, but just from a subjective perspective, I notice slightly worse performance from the CPU renderer while scrolling, but nothing major.
Beyond that, though, how often are you scrolling, and how buttery smooth does that have to be to be a good experience? While it does seem smoother side-by-side, I'm not blown away by the difference.
The FPS meter only works with the Metal renderer, so I can't directly compare it and the CPU renderer, but just from a subjective perspective, I notice slightly worse performance from the CPU renderer while scrolling, but nothing major.
Beyond that, though, how often are you scrolling, and how buttery smooth does that have to be to be a good experience? While it does seem smoother side-by-side, I'm not blown away by the difference.
This is useful while catting a large file/tcpdump on an interface with lots of packets, etc.
If that benefits from 60fps, doesn't that imply that it's too fast for you to read in the first place?
It's possible to look for anomalies in scrolling text that's passing by much faster than can be read. (I'm not convinced that requires opengl, but one reason I use iterm is because doing this on terminal with default settings quickly freezes because of infinite scroll. I presume you can turn that off, but easy copy/paste and minimum contrast settings are nice too. Also, the progress meter on large pastes is suprisingly useful.
True.
I have set triggers that color the text / give out osx notifications if there is a string somewhere like Error/Exception.
I have set triggers that color the text / give out osx notifications if there is a string somewhere like Error/Exception.
It's not so much that you need 60 FPS, but in my use GPU rendering makes editing in vim much more responsive.
It basically brings terminal vim on a par with MacVim in rendering speed.
It basically brings terminal vim on a par with MacVim in rendering speed.
I find neovim to be quite laggy while scrolling without the metal renderer. It's the only reason I was so happy about this feature landing.
Is there somewhere we can view the feature roadmap for this? Will iTerm2 support ligatures at some point in the future? I'm also interested in future performance enhancements, and a comparison to terminal.
There is no official feature roadmap, but here's the current plan:
3.2.x will be focused on rendering improvements. The full change log is here: https://iterm2.com/appcasts/testing_changes3.txt
3.3, which is currently under development, is adding a Python scripting API (https://iterm2.com/python-api/) and fixing tab and window titles to make sense, plus adding a status bar.
Feature requests that are candidates for 3.4 are here: https://gitlab.com/gnachman/iterm2/milestones/8
If you have something in mind file an issue. Y'all are my PMs.
There is already support for ligatures (prefs>profiles>text>enable ligatures). The Metal renderer does not support them because that's an extra level of complexity I can't handle in the first release. It would require constructing CTLineRefs which is already the slowest part of drawing. Subpixel antialiasing also makes this really difficult, but since that's going away in Mojave I'll revisit it.
Future performance enhancements that I have in mind are: - Faster tokenization (including revisiting SIMD) - Mojave-specific optimizations (removing subpixel AA and its knock-on consequences) - Move per-frame setup work into a compute shader. This is tricky because some people have CPUs that are relatively faster than their GPUs (thanks Intel!) - Reuse the preceding frame's rendered texture when updating less than a full frame - Move work off the main thread where possible
3.2.x will be focused on rendering improvements. The full change log is here: https://iterm2.com/appcasts/testing_changes3.txt
3.3, which is currently under development, is adding a Python scripting API (https://iterm2.com/python-api/) and fixing tab and window titles to make sense, plus adding a status bar.
Feature requests that are candidates for 3.4 are here: https://gitlab.com/gnachman/iterm2/milestones/8
If you have something in mind file an issue. Y'all are my PMs.
There is already support for ligatures (prefs>profiles>text>enable ligatures). The Metal renderer does not support them because that's an extra level of complexity I can't handle in the first release. It would require constructing CTLineRefs which is already the slowest part of drawing. Subpixel antialiasing also makes this really difficult, but since that's going away in Mojave I'll revisit it.
Future performance enhancements that I have in mind are: - Faster tokenization (including revisiting SIMD) - Mojave-specific optimizations (removing subpixel AA and its knock-on consequences) - Move per-frame setup work into a compute shader. This is tricky because some people have CPUs that are relatively faster than their GPUs (thanks Intel!) - Reuse the preceding frame's rendered texture when updating less than a full frame - Move work off the main thread where possible
Thanks for the infos and of course all your hard word, iTerm2 is an awesome piece of software.
Looking forward to Mojave dropping support for subpixel-antialiasing and maybe iTerm supporting Ligatures with the new drawing engine someday.
Looking forward to Mojave dropping support for subpixel-antialiasing and maybe iTerm supporting Ligatures with the new drawing engine someday.
Yeah, I’m wondering about this too. I like transparent windows and font ligatures so as much excitement as I have about this, I won’t be able to use it unless these limitations can be eliminated. I’ll keep using iTerm regardless, but it would be nice to see the benefits become available for my setup as I do notice the performance issues.
I'd just disable them. Speed and lighterweight (on CPU) rendering are more important that ligatures and transparency, which are both gimmicky features.
I disagree that ligatures are gimmicky in a general sense, but they definitely don't seem necessary for a terminal window. And doubly so if they impact performance.
Ligatures are great in a terminal with the right font. For example Fira Code does some nice things with ligatures for not-equal, 0x, rockets, etc.
This is a Mac program. One of the reasons why the Mac has historically been far ahead of other platforms is because its display could leverage centuries of advances in typography, and not be confined to the a 1970s character cell display designed by illiterates. Ligatures are extremely important for the platform and for the audience.
We're talking about ligatures in console based programming editors.
Not about setting ligatures for print.
So the whole argument is kind of moot. Having ligatures in console vi is not what made the Mac "historically be far ahead of other platform". In fact for the first 15 years of its life the Mac didn't even have a console.
Even in the desktop GUI program world, where ligatures in programming IDEs and editors are a possibility, they're still an extremely fringe endeavor.
Not about setting ligatures for print.
So the whole argument is kind of moot. Having ligatures in console vi is not what made the Mac "historically be far ahead of other platform". In fact for the first 15 years of its life the Mac didn't even have a console.
Even in the desktop GUI program world, where ligatures in programming IDEs and editors are a possibility, they're still an extremely fringe endeavor.
This is true, but terminals tend to be used with monospace fonts that aren't very typographically complex.
That said there may? be languages other than English where ligatures are more than decorative, and would be more useful to have in a terminal.
That said there may? be languages other than English where ligatures are more than decorative, and would be more useful to have in a terminal.
I'm saying, maybe the terminals of today need to be more typographically aware, now that the computers of today can more than support it.
On the list that terminals need to do, being more typographically aware is on the very bottom on my list of priorities.
They could start by not mimicking 50+ year old hardware terminals down to arcane (and performance killing) details, supporting better and more powerful autocomplete and similar interactions, inline images, full colors, and so on...
They could start by not mimicking 50+ year old hardware terminals down to arcane (and performance killing) details, supporting better and more powerful autocomplete and similar interactions, inline images, full colors, and so on...
It’s important to some people but probably not a majority. Ligatures are a best effort kind of thing. Where trade offs must be made, such as drawing performance, I choose to let the user make that choice.
And it sounds like they wouldn't, and that their priorities are different than yours.
I believe in an external world, where not everything is a matter of personal "priority", but certain things are objectively more significant than others.
And I might be wrong, but in that world, ligatures and transparent terminals are not really as important as rendering speed, latency, and/or less CPU load for a terminal emulator.
In fact, even where available, ligatures are a fringe option, adopted by very few people.
(I'm always talking about programming editors. Though even in print, their main domain, they're hardly mainstream these days).
And I might be wrong, but in that world, ligatures and transparent terminals are not really as important as rendering speed, latency, and/or less CPU load for a terminal emulator.
In fact, even where available, ligatures are a fringe option, adopted by very few people.
(I'm always talking about programming editors. Though even in print, their main domain, they're hardly mainstream these days).
I'm never bothered by iTerm2 being too slow or using too much CPU. Using transparency for my tmux profile makes it easier to tell whether the tab I've switched to is a local or remote session. Seeing coding ligatures makes me happy.
Why is the thing I don't notice objectively more important than my convenience and happiness?
Why is the thing I don't notice objectively more important than my convenience and happiness?
It supports them now. I use fira code.
Per the article, the Metal 2 renderer doesn't support ligatures, transparency, and a few other nice-to-haves.
The original asker asked, "Will iTerm2 support ligatures at some point in the future?", so it was indeed a helpful answer to know that it does support ligatures.
I mean, within the context of this thread, it's pretty obvious the original question is asking whether ligatures would be supported in the Metal renderer, since it's explicitly listed as something not supported in the article, and since the asker is asking for the "feature roadmap for this".
What frame rate does the built-in Terminal.app perform at in macOS 10.13?
It's doing 60 FPS; I just checked.
Out of curiosity how does one measure the frame rate of the terminal on macOS?
There’s probably some software tool to give you an internal perspective on it, but if you want to “prove” your frame rate for any application, there’s one obvious way:
1. make the app full-screen;
2. make the app constantly vary the screen output as often as it can;
3. capture the HDMI output of your computer with a hardware video capture box[1];
4. use some scriptable video software to calculate, for the captured video, how many distinct frames (i.e. changes in content from the previous frame) it contains per second, on average.[2]
——
[1] you could also substitute a high-speed camera pointed at your monitor (necessary when the limiting factor is monitor refresh rates.)
[2] Conveniently, if the capture box emits video in a format with inter-frame compression, you can do the new-frame-counting at a low level, without decompressing the video. You parse through the video stream, discarding the “no change” I-frame chunks, and then count the remaining frame chunks grouped by the start-timecode field cast to seconds. Which is, I assume, what OS file-indexing services do to calculate a video’s FPS, for those that do. This answer is slightly high in the case that you’ve got no-change keyframes in the stream, but it should average out to essentially the same number in any video longer than a few seconds.
1. make the app full-screen;
2. make the app constantly vary the screen output as often as it can;
3. capture the HDMI output of your computer with a hardware video capture box[1];
4. use some scriptable video software to calculate, for the captured video, how many distinct frames (i.e. changes in content from the previous frame) it contains per second, on average.[2]
——
[1] you could also substitute a high-speed camera pointed at your monitor (necessary when the limiting factor is monitor refresh rates.)
[2] Conveniently, if the capture box emits video in a format with inter-frame compression, you can do the new-frame-counting at a low level, without decompressing the video. You parse through the video stream, discarding the “no change” I-frame chunks, and then count the remaining frame chunks grouped by the start-timecode field cast to seconds. Which is, I assume, what OS file-indexing services do to calculate a video’s FPS, for those that do. This answer is slightly high in the case that you’ve got no-change keyframes in the stream, but it should average out to essentially the same number in any video longer than a few seconds.
There is 'Quartz Debug', a tool in the 'Additional Tools for Xcode' package by Apple, that one can use to display the Frame Rate.
Never benchmarked a virtual terminal before, but wouldn’t one basically use a timer and a bunch of unbuffered+blocking writes to stdout to determine how fast the terminal is drawing?
from the link
(Prefs > Advanced > Show FPS meter)
This only works for iTerm, and only when using Metal.
That's an iTerm2 specific feature.
Iterm is probably the only thing I miss from MacOS when I'm on my Linux machine.
Check out terminology or alacritty. Linux has a wealth of excellent terminal emulators that IMO vastly outperform iTerm from both a performance and functionality perspective.
A non-exhaustive list of iterm2 features:
- killer tmux integration (tmux sessions on a remote machine behave like normal tabbed panes, no idiotic prefix-key, broken scrolling and selection etc. etc.)
- the ability to rebind just left or right command keys to meta (and leave the other one working for "normal" copy and paste etc.)
- instant replay and generally very sophisticated output and output history handling (e.g. it's trivial to copy the last command's output or autocomplete from output history, all via keyboard shortcuts).
- annotations
- command click to open e.g. files output by ls (which requires keeping track of cwd at output time)
- input broadcasting
- simultaneous search across all terminals
- mature and polished (renders unicode, including line drawing characters reliably, deals with large output history and many tabs etc. just fine)
- image output
Alacrity (whilst interesting) has precisely zero of these features. In fact I'd already be delighted to find a single linux terminal that has tmux integration.
- killer tmux integration (tmux sessions on a remote machine behave like normal tabbed panes, no idiotic prefix-key, broken scrolling and selection etc. etc.)
- the ability to rebind just left or right command keys to meta (and leave the other one working for "normal" copy and paste etc.)
- instant replay and generally very sophisticated output and output history handling (e.g. it's trivial to copy the last command's output or autocomplete from output history, all via keyboard shortcuts).
- annotations
- command click to open e.g. files output by ls (which requires keeping track of cwd at output time)
- input broadcasting
- simultaneous search across all terminals
- mature and polished (renders unicode, including line drawing characters reliably, deals with large output history and many tabs etc. just fine)
- image output
Alacrity (whilst interesting) has precisely zero of these features. In fact I'd already be delighted to find a single linux terminal that has tmux integration.
Also, the ability to have tabs and put the tab bar vertically down the left-hand side of the terminal, but readably: https://imgur.com/a/6qGxNTu This is the thing that I really have to have in a terminal, because I use too many terminal tabs to keep track otherwise: the tabs have to stay readable, and there has to be room for 30-40 of them when I'm working.
On linux, few terminals support this, and the only one that seemed really usable was roxterm, which was increasingly difficult to install as of Ubuntu 17.10 when I last tried, due to the ROX collection being abandoned. It looks like there's new activity in a github repo this year, but I haven't tried it.
I built a very minimal side-tabs plugin for Zeit Hyper, but updates broke it so regularly that I gave up (the plugin was never great, anyway, and avoiding collisions with other tab-affecting plugins was difficult).
There are several other terminals on linux that claim to support side-tabs, but they all have some issue or another (my "favorite" is when they "support" side-tabs by literally rotating the tab bar so that the text of the bar is sideways, distorted, and still shrinks as more tabs are used, which defeats the point of using side-tabs in the first place!).
On linux, few terminals support this, and the only one that seemed really usable was roxterm, which was increasingly difficult to install as of Ubuntu 17.10 when I last tried, due to the ROX collection being abandoned. It looks like there's new activity in a github repo this year, but I haven't tried it.
I built a very minimal side-tabs plugin for Zeit Hyper, but updates broke it so regularly that I gave up (the plugin was never great, anyway, and avoiding collisions with other tab-affecting plugins was difficult).
There are several other terminals on linux that claim to support side-tabs, but they all have some issue or another (my "favorite" is when they "support" side-tabs by literally rotating the tab bar so that the text of the bar is sideways, distorted, and still shrinks as more tabs are used, which defeats the point of using side-tabs in the first place!).
Doesn't work well in Fedora 28 running on Wayland which is my environment.
What IS the closest comparison in Linux land, out of curiosity? I'm using Terminator. It's ok, but I feel no particular allegiance to it.
When describing the frames you are getting from the built in terminal it might be helpful to list the specs of your machine and how it’s being used: clamshell or not. Also how are you all getting the FPS count from terminal?
There are meters that tell you how many frames per second your GPU is pumping out.
Is there any side-by-side video comparison ?
How come it gets disabled when not charging/plugged in? Why not let me choose?
Especially when I would want to test it right now, sitting here on my bed. :)
Especially when I would want to test it right now, sitting here on my bed. :)
Very satisfied iTerm2 user for 7 years here. My biggest question about iTerm2 is: what is the difference between Preferences (⌘ ,) and Edit Session (⌘ I)?
The Dynamic Profiles feature is fantastic -- being able to version control a subset of the configuration document is exactly what I wanted to be able to do. But I'd like to understand the settings interface/model/schema better.
The Dynamic Profiles feature is fantastic -- being able to version control a subset of the configuration document is exactly what I wanted to be able to do. But I'd like to understand the settings interface/model/schema better.
Edit session divorces the session from its underlying profile so you can make local changes to it only
Thanks, and thanks for iTerm2! Btw, I have two 90% complete iTerm2-related projects that I might mention on the mailing list at some point:
https://github.com/dandavison/iterminator
https://github.com/dandavison/iterm2-dwim
https://github.com/dandavison/iterminator
https://github.com/dandavison/iterm2-dwim
There's currently a bug with multi-GPU based MBPs and the new metal renderer. The new metal renderer causes it to always use high performance graphics whether plugged in or not. I had to debug why my battery was dying faster than usual and traced it back to iTerm2 and the metal renderer.
The developer was working on the fix, but I have not seen a fix announced in the release notes yet.
The developer was working on the fix, but I have not seen a fix announced in the release notes yet.
> It is also temporarily disabled under certain conditions:
> [...]
> When your device is not plugged into a charger. This is controlled by Prefs > Advanced > Disable Metal renderer when not connected to power.
Why is the GPU renderer, by default, disabled unless plugged in? I’d assume the GPU renderer uses less power...
> [...]
> When your device is not plugged into a charger. This is controlled by Prefs > Advanced > Disable Metal renderer when not connected to power.
Why is the GPU renderer, by default, disabled unless plugged in? I’d assume the GPU renderer uses less power...
Could it be that waking up the discrete GPU, on laptops that in some cases disable it by default on battery power, takes more juice than rendering in software on the CPU?
Though I wonder how many MBPs in circulation have the dual-GPU configuration...
It's crazy to now see open source projects on Gitlab after the whole Microsoft purchase of Github.
While this may be broadly true, if I remember correctly, iTerm2 has been on GitLab since before the acquisition.
How come it says that it's mirrored from GitHub and "The repository failed to update 8 months ago. Repository mirroring has been paused due to too many failed attempts, and can be resumed by a project master."
Seems like they are still using GitHub but use GitLab for the wiki?
Seems like they are still using GitHub but use GitLab for the wiki?
They use GitLab for the issues I think.
Github’s issue tracker is lousy so issues have been on gitlab since google code slipped this mortal coil. I don’t want to lose my GitHub stars so code remains there. I guess there’s not much reason to change it now even if github does improve.
Using it for a month. It's indeed much faster.
But the old annoying bug to block indefinitely on an accidental wrong Ctrl-Enter keystroke is still there, since about a year. The regexp detection is also pretty unstable and can block the window. Either the Semantic History or url detection.
But the old annoying bug to block indefinitely on an accidental wrong Ctrl-Enter keystroke is still there, since about a year. The regexp detection is also pretty unstable and can block the window. Either the Semantic History or url detection.
Is there any decently fast and simple terminal emulator for Windows?
VSCode / Hyper 2 are GPU accellerated and are really fast once loaded. Because of their use of Electron they are not excactly fast to load, though.
VSCode / Hyper 2 are GPU accellerated and are really fast once loaded. Because of their use of Electron they are not excactly fast to load, though.
I've been using this for the past couple months by using the nightly releases. it has been insane how much higher quality vim feels when you get 60fps scrolling and no banding
Nice but can they make it so iterm2 doesn't always change the width of the terminals by 2 almost every tine i plug the macbook pro i use into the dual monitors at work?
You have a non-touchpad mouse on a dock there that you're plugging into? If so, you can stop this kind of annoyance by setting scrollbars permanently on (or off) rather than auto in System Prefs->General.
Actually, try it anyway as when I first ran into this fix for such things, I didn't have what I thought was a mouse connected, but actually some non-mouse USB device reported to macOS that it also had a mouse on board for some reason.
Actually, try it anyway as when I first ran into this fix for such things, I didn't have what I thought was a mouse connected, but actually some non-mouse USB device reported to macOS that it also had a mouse on board for some reason.
Thanks for the reply. I'll try this since this morning one of my desktops had set all its terms to 72 wide, another to 74 & 78.
It’s a very hard to fix bug when restoring windows when the scroll bar style doesn’t match. I should revisit this.
Has anyone had performance issues with iTerm? What were you doing? I haven't had issues yet so I'm curious.
I switched back to Terminal.app due to performance issues earlier this year. Things were just feeling laggy and slow, especially with Tmux.
Ah, ok. Sounds like Tmux was an issue for a few people.
I switched to using Fish as my shell about a year ago, and there were some performance issues with it and iTerm, at least with my default fish/tmux/vim/vimux setup. I don’t rememeber what it was exactly, I just remember that switching to stock Terminal.app made it go away.
I may try this iTerm beta just to see if it fixed it.
I may try this iTerm beta just to see if it fixed it.
Interesting! I also use Fish primarily. ZSH sometimes and flip back to Bash when it doesn't work well with Fish but still haven't seen issues. Thanks for sharing.
> Ligatures are very hard to support in a GPU-based renderer.
Why?
Why?
You have to analyze a row of text at once to reorder glyphs, which is expensive and cannot be parallelized.
[deleted]
In some of my experimental terminal emulators I've decoupled these and it's not so hard -- there's a piece that processes command output as fast as it can, and then there's another piece that updates the screen as fast as it can, and as long as those two pieces are decoupled then even if your graphics hardware is 5fps it's still fast to cat a file.