:)įor a terminal, all you really need to do for fast performance is to cache glyphs and make sure you don't get bogged down in the shaper. Also check to make sure you aren't copying bitmaps around needlessly copying around 3840x2160 RGBA buffers on the CPU is not fast. Try to reuse Core Text and font objects as much as possible. Apple's APIs can be a bit fussy about their internal caches for example, the glyph cache is (or at least used to be) a global lock, so if you tried to rasterize glyphs on multiple threads you would get stalls. I'm guessing that you're somehow preventing Core Text from taking advantage of its caching. > Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. AFAICT that's the main difference between Terminal and iTerm2, but it's just not feasible for a third-party developer to do. They glued some NSScrollers onto a custom NSView subclass and (presumably) copy-pasted a bunch of scrolling inertia logic into their own code. I do know that they ditched NSScrollView. How is Terminal.app as fast as it is? I don't know for sure. So this doesn't seem like a productive avenue. It also introduces a lot of bugs-layers on macOS are not as fully baked as they are on iOS.

You also lose the ability to blur the contents behind the window, which is very popular. Using layers helps on some machines and hurts on others.

The deprecated core graphics API is significantly faster, but it does a not-so-great job at anything but ASCII text, doesn't support ligatures, etc.

Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. So it's tricky to get right, especially considering how slow macOS's text drawing is. But there have also been a handful of complaints that latency was too low-when you hit return at the shell prompt, the next frame drawn should include the next shell prompt, not the cursor on the next line before the new shell prompt has been read. I'm sure there are some low-hanging fruit here. I'll spend some time looking into iTerm2's latency.

Bash terminal emulator for mac