Subpixel fonts aren't rendered correctly

[20k]

System

OS: Windows
Version: alacritty 0.4.2 (f68de37)
Windows: ConPTY

Logs

Font/Terminal size: 9 with bitstream vera sans mono

Hello! Alacritty doesn't handle rendering subpixel fonts correctly. I thought I'd document the issue in depth:

This is what an example from alacritty looks like:

This is sample text rendered in a different application that is rendered incorrectly, similar settings:

This is sample text correctly rendered with sRGB correct blending:

I had a brief look through the rendering pipeline, as far as I can tell the issue is here:

// Regular text glyphs.
            vec3 textColor = texture(mask, TexCoords).rgb;
            alphaMask = vec4(textColor, textColor.r);
            color = vec4(fg, 1.0);

Combined with this piece of code:

let windowed_context =
            create_gl_window(window_builder.clone(), &event_loop, false, vsync, size)
                .or_else(|_| create_gl_window(window_builder, &event_loop, true, vsync, size))?;

This looks like it tries to create a window with sRGB disabled, followed by making one with sRGB enabled if that fails. Currently alacritty only renders text correctly with sRGB enabled, but there's no reason why both can't work

textColor here looks like alpha for subpixel fonts, which is good, although strictly speaking it is alpha, not colour. The blend equation is

gl::BlendFunc(gl::SRC1_COLOR, gl::ONE_MINUS_SRC1_COLOR);

Using dual source blending, where src1_color = alphaMask, here the linear subpixels

This gives the final result: Foreground_colour * subpixel_alpha3 + destination_colour * (1-subpixel_alpha3). The problem is, foreground colour and destination colour are both in sRGB for the blend equation when sRGB framebuffers are disabled, which makes this blending incorrect. Its pretty straightforward to convert foreground colour to linear colour if the render window doesn't have srgb enabled (although if you use pow(colour, 2.2) i'll complain very loudly, see this), which makes destination colour the issue

One way to resolve this would be to render to an offscreen render target instead in linear colour, which is 4 component linear floats, then manually gamma correct afterwards when you blit back to the main render window. Or, you could create an offscreen sRGB enabled offscreen texture (which shouldn't run into to pixel format issues) and render to that before blitting. Or do both, conditionally depending on whether or not sRGB is available (unlikely to be an issue targeting desktop, but some linux drivers implement sRGB textures weirdly)

Decoupling the correctness of the text from the render window format is probably a good idea, given that it seems to have issues with getting the correct pixel formats from a look at the commit history. The issues here also apply to general colour rendering, and probably the emojis too, but I have skipped over all of that for simplicity

Thanks!

[kchibisov]

This looks like it tries to create a window with sRGB disabled, followed by making one with sRGB enabled if that fails. Currently alacritty only renders text correctly with sRGB enabled, but there's no reason why both can't work

I feel like this is an artifact from some old refactoring removing default sRGB in favor of RGB, I guess now I new why it was sRGB by default in the past, and I guess it's more correct to do. Especially knowing that some systems don't have RGB these days at all. But yeah, it doesn't solve the problem.

I guess it could be temporary sRGB by default instead of RGB, since solution you're proposing could require some rework, and it was historically sRGB by default.

One way to resolve this would be to render to an offscreen render target instead in linear colour, which is 4 component linear floats, then manually gamma correct afterwards when you blit back to the main render window.

I guess that the thing which could work, though it'll require some testing first.

The issues here also apply to general colour rendering, and probably the emojis too, but I have skipped over all of that for simplicity

I guess, but I'm not sure whether it's true on Linux at all, since it seems like there's not difference whatsoever between those RGB/sRGB.

Thanks for your detailed report.

[ivan-volnov]

I believe font rendering is the most important thing that terminal emulator does.
It must be perfect.

Any news here?