Questions about how small can I really get away with

[CraigglesO]

Hey, I'm a massive fan of your work.

I am building a web map engine and I originally used a loop + blinn approach where I prep the vertices with webworkers and create SDFs via the GPU, but the complexity was high, I wasn't supporting all glyph types well, and the cost on the webworkers was too much considering I needed to prep lots of other data for the GPU.

Long story short I switched to MSDF, created a NodeJS wrapper of your work and manage the glyphs in my own way to create some stunning results:

Comparatively, a high enough resolution MSDF has really sharp edges and asian glyphs look absolutely gorgeous. I like to use roughly 22px size per glyph with 6px range for the best results (I like large ranges for nice large stroke effects around the glyph if necessary).

Here's what 16px with 4px range looks like (all Roboto medium+regular fonts)

I noticed the lower I go, obvious artifacts start showing up.

Just curious if there is anything I can do to get the glyphs smaller without sacrificing the quality of the glyphs? If you zoom in on this last picture you will notice it starts getting really confused on where the edges really exist.

Since the browser fetches chunks of glyphs at a time in this scenario, obviously the smaller the better.
Any advice would be appreciated.

EDIT - I just noticed you did some work in May, do you think this could have a substantial effect on the results?

[Chlumsky]

Hello. I think simple trial and error is a good strategy for determining the minimum resolution of the distance fields. If you gradually lower it and start seeing artifacts you don't want, just go back a step. I don't really see any reason to overthink it. Unless of course you want something like automatically picking the resolution based on the specific geometry of any input font that you don't know in advance, but that doesn't seem to be your case.

I can try to explain what the limiting factor is here. Essentially, in the MSDF model, each edge has one of three possible colors. Edges that connect to each other always have a different color. The representation starts to fall apart when two edges of the same color are too close to each other - specifically less than the width of 2 SDF pixels. At that point it is pretty much impossible to distinguish them apart, so artifacts happen. Keep in mind that consecutive edges cannot have the same color, therefore, in a font, this typically happens with edges that are opposite one another in a glyph stroke, e.g. the left and right edge of the letter 'I'. Consequently, the required resolution is lower for bold fonts and higher for thin fonts - you always want glyph strokes at least 2 pixels thick in the output SDF.

As for the work in May, specifically the new edge coloring strategy, can indeed slightly help in some cases. This new coloring strategy (enabled by -coloringstrategy distance) will try to maximize the distance between edges of the same color as much as possible. However, obviously, since we only have three colors to work with, it won't always be possible to assign the colors in a way that would significantly improve the result, but at least in the case of the 'I' rectangle, you can be sure that its top and bottom will have the same color and not its sides. Also, it's worth noting that the implementation of this coloring heuristic is pretty slow, so keep that in mind if you want to use it - it may actually take longer than generating the SDF itself.

As one can deduce from the above, the MSDF approach could be extended to use more than just 3 color channels to improve this (and requiring to e.g. sample two textures simultaneously), but I'm not sure it'd be worth it.

[CraigglesO]

Thanks, this was a great writeup. Really helped visualize what the algorithm is doing and it's limitations. I think that coloringstrategy approach will help a lot though. I will update and rerun with it to see if I can shave a few bytes.

I put a lot of thought into my current GET implementation and I think that is the fundamental problem anyways. I batch images in groups of 100 by their UTF8 code so there is a lot of waisted time and effort. However, I'm using AWS, so I can just have a lambda in front of the request that only batches the glyphs of interest when pulling from S3. This would have massive savings alone and keep data fetches cheap. Fewer cache hits initially, but I'm pretty convinced this is the way to keep fetch size low without compromise on visual aesthetic.

Appreciate your response! Really incredible project.

[CraigglesO]

Hey, finally had time to iterate the glyph infrastructure.

Switching to coloringstrategy I noticed that "fuzzy" pixels where it's "a little less sure if it's inside the glyph" were much better, so that's very cool.

Interestingly though, the sweet spot is still roughly 22px height for thicker glyphs:

18PX:

20PX:

22PX:

I tried different ranges and other variables, but the "a" is a perfect example that when sections get too close to eachother the MSDF algorithm just gets confused.

However, in the end, the real performance issue was in how I fetched the glyphs. My new method is blazing fast, so 22px height is completely acceptable in my opinion. Batches of 50 glyphs come out to ~70kB uncompressed so I'm happy.