gnachman

You have to analyze a row of text at once to reorder glyphs, which is expensive and cannot be parallelized.

It’s a very hard to fix bug when restoring windows when the scroll bar style doesn’t match. I should revisit this.

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.

It falls back to the old renderer in these cases. Transparency will be supported in Mojave.

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.

It existed before I took it over but it has changes quite a bit since then, kinda maybe?

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.

Only if openstep catches up with Apple, or I retire. I wouldn’t hold my breath.

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%.

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.

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

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.

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.

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.

I released a build of iTerm2 last year that accidentally disabled subpixel AA and everyone flipped out. People definitely notice.

But the reason I’m sad is that this wonderful hack was short lived: https://docs.google.com/document/d/1vfBq6vg409Zky-IQ7ne-Yy7o...

My pet theory is that macOS is going to pull in a bunch of iOS code and iOS has never had subpixel AA.

Please fix the dumpster fire that is AppKit! Doing a grep for angry words in my source code and commits reminded me of some traumas over the years…

* Core Data's generated classes are broken for one-to-many relationships

* NSTableView is a total mess. Lots of things don't work quite right. For example, calculating the correct height for a row of wrapped text is nearly impossible without hackily adding a few points here and there.

* In Metal, constant buffers over 64k get silently truncated on some GPUs.

* MTKView is half-baked. Resizing it stretches the window's contents, for example. If you don't use layers it overlaps the window's rounded corners. If you do enable layers, the framerate drops by half.

* The one field editor per window hack breaks expectations every time I use it. It should be done away with.

* NSTitlebarAccessoryViewController is officially supported but was never documented and forces the entire window to use auto layout

Please don't add any features. Just fix the garbage fire you already have rather than throwing more garbage on it.

I guess I made the big time!

The iTerm2 one is interesting because it came too late. Apple's patch disables Sierra's native tabbing. Version 3.1.3 did not disable it completely. I published a fix in version 3.1.4 which came out on October 22, 2017, about a month after Sierra launched. I guess they must have fixed it in a dot release of Sierra, but I won the race and got the fix out before 10.12.1 which came out on October 27.

I'm glad someone's got my back, anyway.

When the metal renderer is enabled the screen updates at 60fps. When it is not enabled, the refresh rate is governed by the current bandwidth. There are cases where the new renderer has lower throughput because it does not use adaptive framerate. I’ll look into this.

It’s good in traffic jams. You can relax a lot more than driving yourself or autopilot at high speed. The worst case scenario is a fender bender.

Aolserver’s legacy lives on?

The first paragraphs here are horrifying: https://www.mv-voice.com/morgue/2001/2001_01_19.supe19.html

> According to Alana Lee, the EPA project manager for the site, the air stripper on the Netscape campus was constructed in 1989, and because of a grandfather clause, is permitted to emit 24 pounds per day of toxic material. > > The current limit for air-strippers is 1 pound per day.

How do you know the variance of your sensors? Do you have to experiment in a controlled environment?

My experience at Google and Facebook is that junior devs are hires in great numbers. Intern season means you can’t find a parking spot because there are so many of them. This article doesn’t ring true to me, but my view of the world is narrow since I’ve only been at big companies. Is he talking about startups? I thought those skewed young too.

Thank you. I’ve been looking for a better explanation than wiggly snakes for thirty years.

That makes sense. Our problems are somewhat different. Do you need to deal with arbitrary combinations of foreground and background colors? For me this was the hardest problem to deal with because of subpixel antialiasing.

Caching is great but it doesn’t help you when paging through a big file where the entire screen contents get replaced on each update. Is that not what you benchmark?

I'm surprised you found creating attributed strings and CTLineRefs was acceptable. These are the main bottleneck in iTerm2's renderer, and I ditched them when rewriting the renderer in Metal. Since ASCII is an important fast-path for us, and other than ligatures in fonts for programmers there's no need to go through all that machinery. Did you do anything clever to get around the slowness of creating NSAttributedString's and CTLineRef's?

iTerm2'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.

I recall seeing a Google tech talk over ten years ago where they talked about cleaning up OpenOffice (or was it StarOffice?) it was memorable because they mentioned it did #define private public. I’m impressed they kept at it and it sounds like it’s going well. Still glad it’s not my project, though :)

I’ve been disappointed with Apple’s response to kernel bugs for quite a while. Closing a large number of ptys at once caused a panic for years. In high Sierra, there’s this, statfs hangs, and proc_pidinfo hangs.