Colors more vivid in neovide than elsewhere

[JeWe37]

Describe the bug
Colors with the same color scheme appear differently as in terminal problems running raw neovim.

To Reproduce
Steps to reproduce the behavior:

The problem is most visible with themes that are not too vibrant by default(but as far as I can tell it is still present everywhere). In the screenshots I am using the shusia option of the sonokai colorscheme.

Expected behavior
The colors should match those of terminal applications

Screenshots

Desktop (please complete the following information):

• OS: Arch Linux
• Neovide Version 0.8.0
• Neovim Version 0.6.0

Additional context
I previously used the older Vulkan version of neovide where this issue did not appear. As is, it makes it hard to properly match color schemes and at least in my eyes, the more vivid colors stand out far too much.

[LoipesMas]

I'm not sure, but I think it might be caused by antialiasing.

Neovide on the left, ST on the right.
From what I've seen, the color in the middle of the character is the same, but edges look differently. In Neovide it looks like rgb split, while in ST (and Konsole too, I think) the edges are just less opaque (whidh is how it should be done).

[LoipesMas]

Indeed, changing font edging from Edging::SubpixelAntiAlias to Edging::AntiAlias fixes that.
Not sure if neovide is doing something wrong, thus making subpixel antialiasing look bad, or if it's just bad.

Subpixel on the right (current main), normal antialias on the left (after I changed it)

[JeWe37]

Right, yes, I just tried it out here too by just trying a solid block where it is more clearly visible, and that got me the same result. The question is the non-subpixel version generally preferable or should I just make a private fork for my own use.

[LoipesMas]

I think some people reported that the fonts look "weird" and this might be the cause. I'm pretty sure non-subpixel is better (or at least more people would prefer it), but I might be wrong. If there isn't a big majority, maybe we could do an option to set which one to use.

[JeWe37]

Well I tried around a bit but I'll give up on making a setting for tonight. The issue is that the whole font renderer is initialized very early on it seems, even before the settings are read from neovims config, meaning that tweaking anything there won't really help unless you make it update properly. Given that I honestly barely use Rust at all and am not that familiar with the code I'll leave it at that. I just statically changed it for myself for now, which fixes the problem for me.

[Kethku]

Ok so it seems that the issues is fixed for now and nobody has really asked for subpixel font stuff from us since so I'm going to close this.

[orlandosh]

Sorry for commenting on a closed issue, but I have this issue as well. Would you please tell us in more depth how you solved it locally @JeWe37 ?

[JeWe37]

I don't use Neovide anymore, but it seems that this has become configurable since then, see here

[orlandosh]

g:guifont = "MonoLisa Neovide:h15:b:#e-subpixelantialias:#h-none" (https://neovide.dev/configuration.html#font) didn't help, colors still vivid compared to kitty. thank you anyway. I will try with another font later to see if it's font bug.

[fredizzimo]

Can you check if it's the font or the colors in general, by setting the background color for example
:highlight Normal guibg=#FA8072? Then check with a color picker what values you get in Neovide and the other terminals.

You can do the same for the fonts by setting a big font to rule out any edging issues and then use guifg

Edit: At least on Windows with the default settings the background is exactly as specified, and the fonts are the same or darker (with a darker background). Subpixel antialiasing, which could make some pixels brighter is no longer the default on any platform.

[orlandosh]

Edit: my display runs on 30bit

Original comment:

sure. tested with monaco and menlo (i found them in my font book app), and same thing
kitty(right colors):
neovide:

colorpicker results
neovide:

kitty:

Edit: I just saw your edit, and I disabled to test without subpixel antialias, and same results.

I'm on macOS, latest version, neovide 0.11.2

edit again: I tested on both the homebrew formula and the cask, same results
edit: font size = 50
neovide:
kitty:

[fredizzimo]

It depends on how you define "correct"

The output from Neovide is 250,128,114=#FA8072, exactly as specified in linear RGB values. On the other terminals the output is converted to sRGB 232,137,118=#E88976

Apparently the built in macOS terminal chose to use sRGB for some unexplainable reason, and the other terminal emulators were forced to follow.

• Use sRGB color space for NSWindow on macOS alacritty/alacritty#6602
• Colorspace of truecolor renderings kovidgoyal/kitty#2249

That also means that a color scheme designed on Linux or Windows will look wrong on macOS and vice-versa. But apparently that's what macOS users want, so I'm not opposing creating an option to enable sRGB output, but I'm not sure about making that the default.

I acknowledge that the sRGB format is superior, especially since most new monitors are wide gamut, but terminals have traditionally used linear RGB. Most web browsers use sRGB though, and therefore the sRGB colors will match the ones you see in a color picker in the web browser, while the linear colors match the colors you see in most other applications including simple painting programs like Microsoft Paint.

I will however, not re-open this issue, since it was originally clearly about the fonts. If you want sRGB support, you should create a new issue for it.