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
Can you verify if everything is correct?
Thanks,
Anuj