Hello Alexei, First, about using squared distances instead of `FT_Vector_Length', it is much faster to use squared distance. I tested it with linear case and it comes around 0.114 microseconds, which is almost 65% faster than the original time of ~0.32 microsecond. It isn't 90% faster because there is one vector normalization which can't be avoided. Moving on, I think it's not possible to store squared distance using 16.16 fixed point because it can store a maximum of 32668 which is a square of ~181, so if the glyph is more than that, then there is a problem of overflow. If I am allowed to use decimal representation instead of binary fixed-point for internal computation then It might be possible.
> *So each curve is sampled a large number of times [...]* I'm not sure I understand it correctly, here is what I understood: You want to divide the curve in a large number of flat segments. Then calculate the distance of the pixels very near to the curve (the pixels will have a unique projection on the flat segments and no two will be the same). Now using these pixels (which have a unique projection), calculate the distances of the rest of the pixels/grid. Is that correct? And finally I have a small request, I have added a new `sdf' module in my branch ( https://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=anuj-distance-field ) Can you verify if everything is correct? Thanks, Anuj
