I believe the main problem here is that what iced and glyphon are doing is technically the correct color space handling, but no other application interprets the alpha channel of glyphs this way, so while technically being more correct, it ends up looking very washed out and inconsistent with other applications.

Indeed! This is not just a color space issue, but also an alpha blending issue.

Most GUI toolkits operate (e.g. perform alpha blending) on sRGB colors while assuming they are linear. See Web color is still broken.

iced tries to do the correct thing by default. If you want "broken colors", you can enable the web-colors feature.

web-colors disabled

web-colors enabled

I'm well aware of those color space issues and I actually really like that you even have a toggle for it. And in fact I did mention that what you do is for sure much more correct than what other applications are doing. I think the question still somewhat remains if it should affect the font rendering to this (negative) degree. Like I believe even without "web colors" it should probably behave this way for blending the fonts.

I think the reason why the wrongly blended text looks better is because for low resolutions (i.e. normally sized text on non HiDPI screens), the higher contrast makes the glyphs look a lot more legible than doing the correct blending.

Like I believe even without "web colors" it should probably behave this way for blending the fonts.

I'm happy to consider our options here, as long as we know what we are doing.

Gamma correcting an alpha channel seems quite strange. It does improve the final alpha blending result, but it feels like we are just smashing things. How is brighter text on a dark background affected? Is there any previous work on this?

In order to produce the web-colors result only for text, we would not be able to rely on hardware color conversions. We would have to declare every texture as linear RGB and manually do all of the sRGB conversions in the shaders, except for the text one. Or maybe declare a dedicated render pass for every text layer... equally undesirable.

We could also consider enabling the web-colors feature by default, since it's in the end what will be expected from most users.

It is quite unfortunate that we have to adopt a broken rendering technique just because it's become the norm, though.

Is there an option of doing something like stem darkening? Freetype experimented with it (as explained here in an article from 8 years ago) as a way to offset the "washed-out" look.

@TheDecryptor Yes! I remember that paper! I think it would certainly be an interesting feature for glyphon when using ColorMode::Accurate.

cc @grovesNL

Yeah that could be useful for sure, I'd like to understand the state-of-the-art for this better before we decide on stem darkening though. If I remember correctly some approaches for this problem don't work well with display scaling (especially macOS versions in the last decade or so) but don't have a reference handy right now.

IANA text rendering expert, but I remember someone in Gnome saying RGBA blending can't do the right thing with subpixel AA on both dark and light backgrounds, and per-channel opacity is needed.

Freetype's Harmony renderer has an interesting first-principles approach to AA, where subpixel rendering is seen as a correction for hardware's misaligned color planes, instead of some kind of "triple resolution" hack. It could be implemented directly at some performance cost by rendering color channels separately and swizzling at the end. That handles vertical and triangular subpixel arrangements just as easily as horizontal, although I don't think it's quite right for RGBW which could have color-dependent offsets.

It is quite unfortunate that we have to adopt a broken rendering technique just because it's become the norm, though.

Perhaps text and graphics should be treated separately? The font designer was probably looking dark-on-light output rendered with that broken technique when tuning the small sizes, so in some sense it is ultimately correct. The text renderer could attempt to adapt the appearance of incorrectly-blended dark-on-light to whatever the actual output target is.

And then color emojis are a whole 'nother kettle of fish.

Perhaps text and graphics should be treated separately? The font designer was probably looking dark-on-light output rendered with that broken technique when tuning the small sizes, so in some sense it is ultimately correct. The text renderer could attempt to adapt the appearance of incorrectly-blended dark-on-light to whatever the actual output target is.

Yes. As I said in my previous comment, we could do it but it seems it would cost us performance and composability when it comes to our rendering primitives. But I'm not a graphics wizard, so maybe there is a way!

And honestly, adding a bunch of complexity to our renderer architecture so we can basically accomodate a broken rendering technique sounds quite painful.