totalgood.blogg.se

• #How to open a terminal emulator mac software#

Even there, some improvements can be made:

#How to open a terminal emulator mac software#

There is hardware and kernel buffering that userland software can do little about, admittedly, that can easily add up to getting you above 100ms as you say. Your reply also reads like games are getting away with introducing 100s of milliseconds of additional latency, which just isn't the case for the most part. There are a few optimizations which focus more exclusively on one or the other, but my experience is that they tend to be rarer. an average 48ms frame time, or a 100+ms frame stall, will improve both throughput and worst case latency. And while throughput and latency might be orthogonal concepts, they're not nearly so orthogonal in practice when optimizing. Some of the listed problems are throughput problems, not latency problems (both in this thread and the original article), so it's not a mistake to address both types of performance problems. There's a lot lower hanging fruit than adopting Pathfinder, which is undergoing a major rewrite anyway. Pathfinder would help when the cache is cold, but on a terminal the cache hit rate will be 99% unless you're dealing with CJK or similar. :)į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.