Sub-pixel anti-aliasing

[tobia]

I'm having a strange bug. I have configured my new system (Arch Linux) to use sub-pixel anti-aliasing in my ~/.config/fontconfig/fonts.conf

Every app I have tried so far follows those rules (Firefox, Chromium, Leafpad...) except Kitty, which uses a default grey anti-aliasing, no matter what I specify.

Using strace I can see that it opens the same FontConfig library as the other programs: /usr/lib/libfontconfig.so.1 and that it sources my local config file correctly. But then it seems to just ignore it. Or maybe it turns the glyphs into monochromatic after the font has been rendened? I dunno.

I'm using the Sway window manager, which is Wayland-based. Could that be it?

[kovidgoyal]

kitty does not support sub-pixel rendering. Supporting it would require both a performance hit (all cached glyph images would become three times larger and alpha blending would require three separate per-channel calculations) and also a fair bit of code complication. Given that on newer high DPI displays, there is not much point in sub-pixel rendering anyway, I am not interested in implementing it.

[parthsdoshi]

While I agree that it's not needed on newer hidpi displays, I would argue that most people still use their "older" monitors that are probably not hidpi. Would you be opposed to sub-pixel rendering being an optional feature either chosen in run-time or compile-time?

[kovidgoyal]

In order to do sub-pixel rendering one would have to render to an offscreen buffer first (in order to do correct alpha blending), this has significant performance implications and code complication implications. As such I'm not really in favor of it. But you are welcome to send a PR and I will review it, and might merge it if it has no negative performance implications when disabled and reasonable code complication overhead.

[tobia]

As the OP, I have to say I agree with @kovidgoyal. Sub-pixel anti-aliasing would substantially lower Kitty's rendering performance. Also, if you have a low-res screen, there's less reason to use an OpenGL-based terminal emulator. Traditional rendering techniques were and still are good enough.

In fact, on low-res screens I still prefer uRxvt with my favorite hand-drawn bitmap font, GohuFont 14px, no anti-aliasing at all. It looks so much sharper than any kind of anti-aliasing. (If you have a mid-res screen and 14px is too tiny, I recommend the fixed 9x18 font from the standard X11 font package.)

[parthsdoshi]

I would agree with you but I think there are a lot of people out there who have a hidpi laptop but connect the laptop to a non-hidpi monitor. I'd like to be able to use the same terminal seamlessly wherever I am without having to switch.

But of course, if the performance hit is as drastic as you say; I can see why someone wouldn't want it to be added.

[slavoutich]

Pity. This is a great terminal emulator, but fonts look really ugly on my 1920x1080 15 inch.

[strange]

Yes, it's a pity. Looks like a very nice project, but the font rendering is awful compared to urxvt on my setup (Arch, dual Dell 27" 2560x1440, Deja Vu Sans Mono at 11pt). But it's hard to argue with the reasons outlined by @kovidgoyal. Will keep an eye on the project, keep up the great work!

[pkazmier]

Maybe it’s years of using a Mac, but I love the look of “thicker” fonts. I, too, am struggling with the awesomeness of Kitty with the ugliness of my fonts (Pragmata Pro). Every time I think I’ve come to grips with it, I accidentally open up iTerm and realize that I’m kidding myself - I just prefer the sub-pixel aliasing. I must be in the minority though as I never understood why iTerm and other programs (VS Code) give options to disable it. Nonetheless, thanks for a fantastic terminal! Your level of support is outstanding!

[kovidgoyal]

I can totally appreciate that, once you get used to a certain look, it is very hard to adapt to a change. I have this issue all the time when I am forced to work temporarily on third party computers, I just cant get used to how the fonts look :)

As I said, I am willing to merge a patch that has no overhead when disabled and reasonable levels of code complication.

[slice]

I attempted this by tweaking the render_glyphs function: https://github.com/kovidgoyal/kitty/blob/master/kitty/core_text.m#L364-L365

I tried various combinations of function calls:

• CGContextSetShouldSmoothFonts
• CGContextSetAllowsFontSmoothing
• CGContextSetAllowsAntialiasing
• CGContextSetAllowsFontSubpixelQuantization
• CGContextSetAllowsFontSubpixelPositioning
• CGContextSetShouldSubpixelQuantizeFonts
• CGContextSetShouldAntialias
• ...

However, disabling and enabling a variety of these CoreText APIs had no effect.

I did more research into how terminal emulators like iTerm2 and Alacritty did "thin stroke" rendering. Both of those emulators have options to enable and disable thin strokes. It turns out that there is a semi-private (?) smoothing style API:

extern void CGContextSetFontSmoothingStyle(CGContextRef, int);
extern int CGContextGetFontSmoothingStyle(CGContextRef);

This API is also used in WebKit, which is how people found out about it.

Passing 16 (2 << 3) into CGContextSetFontSmoothingStyle would enable thin strokes. But this isn't useful to us as the strokes are already thin.

I tried some other numbers to pass into the function, but they didn't appear to revert back to the thick strokes.

• Alacritty: https://github.com/jwilm/alacritty/pull/277/files#diff-91c8eb5607beecf6f1ff9718907e2df6R408
• iTerm2: https://github.com/gnachman/iTerm2/blob/5661e5681f1d19aad28a33a30b9b1380b48962a2/sources/Metal/Support/iTermCharacterSource.m#L266

Kitty's font rendering mechanics might be forced to thin strokes because of how the views are backed, maybe? Or how Kitty works at its core?
It doesn't seem that tweaking the CoreGraphics context may help, but maybe I just didn't try hard enough...

I hope this helps!

[kovidgoyal]

Yeah tweaking coregraphics parameters will have no effect. Unlike most (all?) other terminals kitty achieves its performance (partly) by storing alpha masks of each character on the GPU. So every character is rendered only once. A render in kitty just means sending the indices for each apha mask to the GPU. This alpha mask is then blended with the foreground color, background color, and any negative z-index graphics and drawn to screen, all on the GPU.

So to enable sub-pixel rendering, you have to first:

1. Generate three-channel alpha masks from the font drawing library (CoreText or FreeType)
2. Render the background and any negative z-index graphics to an offscreen buffer (an FBO in OpenGl parlance)
3. Blend the three channels onto that buffer, with gamma correction
4. Render positive z-index graphics on top
5. Done

[kovidgoyal]

Just FYI, Apparently Apple agrees with me, they are removing sub-pixel antialias completely in 10.14 https://infinitediaries.net/removed-in-macos-10-14-mojave/