Font aliasing on web (dark mode)

[ShadowJonathan]

Browser version: Version 1.25.73 Chromium: 91.0.4472.106 (Official Build) (64-bit)

OS: PopOS 20.10

[crumblingstatue]

I get the same behavior. Something has regressed since last version.

[EmbersArc]

Looks like this both in Firefox and Chromium based browsers on Linux. It looks fine on mobile, probably because of the higher dpi.

Another thing pointing toward alpha blending to be the issue is that the slightly transparent parts of the plot disappear almost completely in the web version.

Here are the native and web versions side by side:

[parasyte]

It also appears this way in Edge 91 on Windows 10. The issue is limited to the egui_web build.

git bisect found effd3c7, which makes perfect sense.

Updated 2 paths from the index
effd3c7440d9f70c0eff677871a60be539cf1113 is the first bad commit
commit effd3c7440d9f70c0eff677871a60be539cf1113
Author: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Date:   Fri Jun 4 23:03:48 2021 +0200

    egui_web: Vastly improve WebGL alpha blending

    This finally fixes the rough edges on text, especially in light mode

 egui_web/CHANGELOG.md                   |  1 +
 egui_web/src/shader/fragment_100es.glsl | 23 ++++++++++++++++++-----
 egui_web/src/shader/fragment_300es.glsl | 23 ++++++++++++++++++-----
 3 files changed, 37 insertions(+), 10 deletions(-)

This work was done in response to #454

[parasyte]

To be honest, the light theme really does look a lot better with that patch, but it still breaks blending unfortunately. See before and after with the light theme:

[EmbersArc]

I did some testing and it's this line that has a very negative effect:

egui/egui_web/src/shader/fragment_300es.glsl

Line 36 in 4f6dac2

gl_FragColor.a *= sqrt(gl_FragColor.a);

[ShadowJonathan]

(Thanks for the quick responses!)

[X-Ryl669]

I did some testing and it's this line that has a very negative effect:

egui/egui_web/src/shader/fragment_300es.glsl

Line 36 in 4f6dac2

gl_FragColor.a *= sqrt(gl_FragColor.a);

If I understand the code correctly, this compute a raised to the power of 1.5 for light mode. It's a magic number that seems to break for other theme. If I'm right, change that line to gl_FragColor.a = pow(gl_FragColor.a, 1/1.5) and it should be better on dark themes, since it'll use the inverted power for alpha blending.

[emilk]

The web renderer has always had a problem with pixel perfection (aligning a html canvas to the physical pixel grid is something I haven't yet figured out), which has lead to slightly blurry text in some cases. In egui 0.13 I changed (improved) the gamma curve in the web renderer, which makes fonts slightly thinner. This makes the pixel-imperfection/blurryness much more noticeable.

So: the best fix would be to figure out how to perfectly position a webgl canvas. Alternatively, we make the fonts thicker again to cover up the problem.

[EmbersArc]

Really fixing it may take some more effort, but in the meantime I'd suggest removing the line with the blending tweak since it has a very negative effect on the visuals for both themes. If the shadows look too dark in light mode then we should probably fix this in a different way.

We could also consider @X-Ryl669's tweak gl_FragColor.a = pow(gl_FragColor.a, 1/1.5), in my opinion it has a positive effect on both themes (again except for the shadows in the light theme).

Light mode with the current tweak and without:

Dark mode with tweak and without:
Also note that the filled area in the plot is almost gone with the tweak

[ShadowJonathan]

imo, the "without the tweak" variant looks much less weird to me.

(also lol that plot)

[parasyte]

If we're just going to throw around empirically derived numbers, I think gl_FragColor.a = pow(gl_FragColor.a, 1/1.5) produces colors that look reasonable, IMO.

It creates a wild curve with dark tones, which you can see in the shadows on the light theme. But the curve is less pronounced than multiplying (!) by the square root.

[X-Ryl669]

Honestly, changing gamma is just a hack. One should match what the monitor's gamma is showing here, not rely on hardcoded numbers. Also a * sqrt(a) = a^1.5 = pow(a, 1.5). Depending on your monitor gamma level, it can be better or worse. My tweak is simply to undo the monitor's gamma a bit (a monitor performs x^1.8 or x^2.1 depending if it's a Mac or Windows), so if you want to be pseudolinear here on the output, you must perform (x^1/1.8) first, or (x^1/2.1) so that the actually displayed value is x.

The right fix is to either not rely on gamma at all (that is, try to avoid as much as possible antialiasing/alpha blending with different color) by using larger font or bitmap font, or query the monitor's gamma, invert it, perform your aliasing with the anti-gamma value and let the monitor reapply the gamma correctly.

[emilk]

It might also be possible to get linear blending when rendering to a texture in WebGL instead of rendering directly to the framebuffer, but I haven't tried it.

[billyswong]

Hi maybe "make the fonts thicker" is actually a proper solution! I came across an article in https://www.freetype.org/freetype2/docs/hinting/text-rendering-general.html

Assume we render fonts correctly. Gamma correction essentially lightens fonts since shades of gray are shifted to higher pixel values (corresponding to higher brightness) to match the original intention to the reality of our screens. The side-effect is that glyphs that were rendered incorrectly but fairly readable suddenly thin out. Correctly rendered but hard-to-read text doesn’t do anyone a favor. So Mac OS X and Adobe’s proprietary font engine implement a counter-measure: stem darkening at smaller sizes where shades of gray dominate. By emboldening a glyph slightly in relation to its pixel size, individual pixels get higher coverage of filled-in outlines and are therefore blacker. This increases contrast and prevents thinning out of glyphs. Text remains readable at smaller sizes.

So making the line / font thicker is actually what the big companies and big open source projects did.

[parasyte]

That's exactly what I did for an app I'm working on, but for different reasons. Even when font rendering is not terrible (see egui_glium) a dark font on a light background looks worse than the same font with a light color on a dark background. I switched to a slightly heavy font weight for the light theme to make it appear roughly the same thickness on both.

This issue is a bit different, because the gamma curves are way off. You can see it mostly where alpha < 1.0.