5 ms·
I must concur. With an equivalent vim setup and code files, nothing beats X11/suckless terminal on my OpenBSD machine. Comparing to that, even Alacritty looks l
by eeks 9y ago
I must concur. With an equivalent vim setup and code files, nothing beats X11/suckless terminal on my OpenBSD machine. Comparing to that, even Alacritty looks like a slug.
I must say however that things are looking a bit better in iTerm2 when switching the Metal renderer on. It's just a shame that an Nvidia GPU on OSX is necessary to compete with my $1000 Lenovo with its crappy Intel chip on OpenBSD when it comes to text editing latency.
- tomjakubowski 9y agoHave you tested iTerm2's Metal renderer performance with the integrated Intel GPU?
- eeks 9y agoYes, however matter-of-factly while moving about the office. I did not perceive any difference between the Mac plugged in and on the go.
- Philipp__ 9y agoWow, just gave iTerm2 Nightly with Metal renderer a spin! Holy shiet it's fast and smooth! FINALY! Opened 20k C file in Vim (stock vim 8 that comes with macOS High Sierra), pushed that scroll down and let it roll, it was soooo smooth! Amazing!
- wyclif 9y agoIs there a way to install that with homebrew?
- bhoeting 9y agoI tried it after reading this comment. You weren't kidding. Unfortunately, my Vim isn't rendering properly. About 10 lines in the middle of the screen are blank for some reason. Both in and out of Tmux. Oh well. I'm just happy that I can look forward to Metal rendering being merged into stable.
- neoncontrails 9y agoNot sure if it's the same issue I had recently with iTerm2 periodically going black, but consider disabling the Core Text renderer with the following command: $ defaults write org.vim.MacVim MMUseCGLayerAlways -bool YES This was the developers' suggestion and it solved my issue. There's an informative discussion of the root causes here: https://github.com/macvim-dev/macvim/issues/557 https://github.com/macvim-dev/macvim/issues/557.
- bhoeting 9y agoHmm, that didn't see to work for me. I think I have a different issue. Thanks, though!
- gnachman 9y agoiTerm2's design is saddled by some history. At the time I took it over, everything was done in a single thread. By the time I realized I was going to stay with the project and how bad the design was, it was too late to change it. I've moved as much work as possible off the main thread (parsing the bytestream and now rendering). I think Terminal gets very nice performance without resorting to Metal by doing only UI work on the main thread. I think the Metal renderer will prove to be worthwhile, even though it was a lot of work to create that could've been avoided (kinda) if the design had been fixed 8 years ago. As for using CPU when idle, there was a bug where a background thread was doing the equivalent of running `ps` over and over. That's been fixed in the last few versions, but please file issues for such things and I'll get to them as soon as I'm able.
- wll 9y agoThank you for your work on iTerm2, George!
- jarpineh 9y agoI'll add my thank you. I'm also backer at Patreon. With tmux control mode it's already very good and now with faster rendering coming...
- acoard 9y agoI've got an unrelated question about tmux/iTerm2 - hope you don't mind me asking. I'm a heavy iTerm2 user and always been curious about tmux. Is there any reason to try out tmux integration if I'm already comfortable with iTerm2's features and panelling? I kind of got the impression tmux integration was largely for people who love tmux and are migrating to iTerm2, so it just makes it more familiar. Or is it something I should take another look at?
- AceJohnny2 9y agoI use tmux with iTerm regularly, and it's my killer feature in iTerm. I don't think there's much benefit to using tmux integration for a local shell, other than possibly long-lasting sessions that will survive iTerm itself crashing (and maybe you logging out? I'm not sure), which isn't enough of a problem for me to have to work around. The awesome benefit for me is when using a remote tmux. Tmux integration works over SSH, so thanks to this I can have native-looking tabs and windows that are actually terminals on a remote machine. And if I get disconnected (frequent, with a laptop, as I'm moving around), I can reconnect and get all the remote windows just fine. Gone are all the usual tmux C-b prefixes to managing windows, non-integrated scrolling, etc. Everything behaves like a normal iTerm window. I can even split/move panes like normal iTerm panes (though that crashed iTerm until about a year ago). I have the following alias defined: ssh -t elf.example.com /opt/local/bin/tmux -u -CC attach The -t is the SSH option to force pseudo-terminal allocation, which some versions of ssh fail to do when passing a command (in this case tmux) rather than starting a shell. I'm specifying the /opt/local/bin version of tmux, because that's an updated one I've installed from MacPorts. Unfortunately Apple continues to bundle old versions of tmux in macOS, and last I checked the one that was bundled didn't actually support the Control Channel required by iTerm integration. -u is a tmux option to force it in Unicode mode, required by iTerm's Tmux integration -CC tells tmux to start a control channel and disable echo (required by iTerm's tmux integration) `attach` attaches to the default session that I created prior.
- bowmessage 9y agoThank you so much for mentioning the new experimental metal renderer feature. This has dramatically improved my development setup.