Same here. For scaling from medium to large fonts the MSDFs were good. However at smaller "normal" font sizes they just didn't tend to look good even with larger MSDF sizes.

Plus for font rendering the GPU overhead was too large to be worthwhile for normal GUI apps. Font atlas'es are pretty small, and most fonts for GUIs are statically sized.

However I did find MSDF are fantastic for rendering complex SVG paths with lots of benefits [1]! You can use a 64x64 SVG star and scale it up fullscreen with reasonable loss in quality [2] (or use 128x128 for almost lossless images).

I use them as the core of my GUI library to render complex SVG paths for icons and such and compose individual paths on the GPU.

You can use them to implement fair chunks of Lottie animation as well [3]. Though I never got enough into the Lottie work to go beyond basic demos, but you could easily scale MSDFs, add shadows, feathering, outlines, etc at 100+ FPS.

1: https://forum.nim-lang.org/t/14062#85314

2: https://github.com/elcritch/figdraw#msdf-bitmap-based-sdf-re...

3: https://github.com/elcritch/lotty

It does give you an anti-aliased value between 0 and 1 that estimates how much of a pixel is being covered.

But this is a linear estimate based on horizontal and vertical distance to the Bezier curve. It does not look correct at long distances, which is why you shouldn't use it for outlines, drop shadows or the other cool things you can do with (M)SDF. A single pixel outline works fine but is not really legible with modern display resolutions (very thin lines).

For finding the minimum distance between a quadratic Bezier curve and a point would require solving a 3rd degree polynomial, where Slug's algorithm gets away with solving a quadratic equation per pixel. This is makes a big performance difference.

That said, there are interesting effects other than grayscale antialiasing, and I wonder how well slug could handle things like outlines (useful for subtitles over video, to make them readable on any background).

the reason slug has two bands is precisely because of its anti-aliasing. you having only one implies you do the AA differently, or are less efficient with searches off the main direction.

for readers: the slug shader traces two rays, one horizontally, and one vertically, to find out if a pixel is inside a glyph or outside. one would be enough for pure inside outside, but for anti-aliasing purposes it's also helpful to know how far away you are from the closest edge. but if you have a horizontal ray running parallel to a horizontal glyph edge (not uncommon), the ray glyph intersection will return no value at all. so slug traces two rays and blends between them for anti-aliasing that always works in both cases. the bands mentioned here are just acceleration structures, basically a list of cells where each tells you which parts of a glyph are contained within it.

it's still approximate. a true ground truth would just supersample and do many point-in-glyph tests within one real pixel - at edges some of them would be inside, and some of them would be outside, giving you a smooth value to display depending on the shape of the glyph within the edge pixel.

It does bias me negatively towards the author, and makes me a little sad that people are choosing to not put more thought and effort into their writing, but this is a trend that is here to stay.

Making a big fuss about this hasn't gone anywhere from what I can tell, and it's unlikely that the outcome will be any different going forward.