Re: [Freetype-devel] Re: GSOC - Distance Fields

[Alexei Podtelezhnikov]

On Thu, Jun 18, 2020 at 8:01 AM Anuj Verma <anujv@iitbhilai.ac.in> wrote:
>
> Hello Alexei,
>
> First, about using squared distances instead of `FT_Vector_Length', it
> is much faster to use squared distance. I tested it with a 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.

Ok. This means that square-distance might need to be represented as
26.6, for example, but this also means that short distances will lose
accuracy. Hence the question, which distances contain more important
information? I would argue that it is the short distances to proximal
grid points because those contain the information on how to thread the
boundary through the grid. The distant grid points contain very little
additional information as they might even be closer to a different
segment. So, 16.16 is still better and truncating at 181 should not be
a problem. Also 181 is far considering a typical distance field grid
size. Is there a way you can test if truncated distance fields work
(TSDF)?

>
> > 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?

As I said above, the distant grid points contain very little
additional information or even "belong" to a different segment. All
grid points should be calculated and truncated alike. The idea is to
use a coarse *slightly* jagged representation of all curves and grid
points. FreeType smooth renderer walks along the outline (using
FT_Outline_Decompose) and generates small linear segments along the
curves.

>
> 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?

Looks alright, including modules.mk. Have you checked if it compiles?

Best,
Alexei