Hacker News Reader

Comment by gnachman | Hacker News Reader

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?

View on HN

There's caching all over the place so that you don't end up redoing the expensive stuff (ie creating attributed strings & CTLineRefs). It seems to work pretty well in terms of maintaining 60fps.

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?

That is correct. I'm measuring scrolling at low to medium speeds, where the majority of the text hasn't changed (this also corresponds to most editing tasks). I don't want to make the claim that I'm keeping up when scrolling at very high speeds. I think my assumptions are reasonable for an editor, but for a terminal scrolling at high speed is much more common. I have certainly considered fast-pathing monospaced font rendering (it would certainly be easy in the current architecture, and in fact we're doing that for the gutter numbers), but it hasn't seemed absolutely necessary, and going forward I want to make sure that rich text and i18n aren't treated as second class wrt code.

Keep in mind a lot of less-sophisticated users will just mash navigation keys (or click-drag the scrollbar) instead of using more sophisticated navigation commands. If high-speed scrolling isn't reasonably optimized, it will be noticed.

Yeah also I recently tried Xi-mac and the first thing I did to see how fast it was was to drag the scroll bar quickly. Based on my experience of other editors that is where they usually get slow (no editor seriously has problems inserting one character at a time).

Unfortunately Xi was quite laggy in the scrolling department. Slower than VSCode for example.

Were you perhaps on a debug build? This would be quite surprising in a release build.

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.

Yes, and I'm quite proud of how that turned out. It's using linear sRGB color space, so colors are blended with correct gamma, and dual source blending for the LCD subpixel stuff. It's all handled inside the graphics hardware; if you look at the code it's pretty simple and accessible.

Reply on news.ycombinator.com