I fiddle in this area as a hobby project. One thing I never understand when I read announcements like this is why the graphics performance affects the throughput. Like in a video game, the world moves at the same rate regardless of the frame rate, so why are the two related here?
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.
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.
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.
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
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.
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 :)
> 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.
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.
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).
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?
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.
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.
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.
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).
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?
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.)
> 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.
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.
This optional feature is the other way around. When you turn it on, the connect to a remote servers, that remote server can run commands on your local box.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
"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."
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.)
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.
* 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
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.
> 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
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.
>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.
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.
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.
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.
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.
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
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 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 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
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.
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.
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.
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.
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.
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.
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:
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
Then edit your ~/.zshrc plugins
# Plugins
plugins=(zsh-autosuggestions)
Then restart and type some commands. re-type a command you did and push control+e to complete it. I recommend re-binding your caps lock key to control for vim and also tons of hotkey ease of use. then you can just use caps+e for instant fast typing.
Combine this with using control+p to cycle through previous commands means you can be a wizard at commands quickly
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.
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.)
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.
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.
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.
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.
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.
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.
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
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.
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.
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...
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.
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).
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?
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".
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.
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?
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.
- 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!).
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?
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.
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.
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...
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?
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.
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.
I did try this a while ago (with ConEmu instead) but got into some filesystem issues when working outside of the lxss owns filesystem. You have no issues there?
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.
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.
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.
This will be fixed under macOS 10.14! It's already enabled on the nightly builds. The blending isn't quite right yet, but I only had a few hours to spend on it.
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.