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

[Alexei Podtelezhnikov]

On Sat, Jun 20, 2020 at 7:38 AM Anuj Verma <anujv@iitbhilai.ac.in> wrote:
> Secondly, I did try subdividing the conic curves, for start I simply divided
> them into equal parts and used that to generate SDF. I saw that it require
> at least 32 divisions to produce a decent SDF, which in itself is quite slower
> than simply solving the cubic equation (and there can be many curves in the
> glyph).
> Moreover, I overlooked the fact that around the corners there is a corner 
> check
> involved, which is done to determine the sign correctly around corners. So,
> subdividing the curve also increases that which is around ~0.13 microseconds
> for each pixel around the corner.
>
> Looking at this I now think that it's not worth splitting the curve into 
> lines for
> generating the SDF.

Hi Anuj,

Thank you for the analysis. What you describe make sense if you:

foreach gridpoint
   foreach curve or line
      do work

Then, of course, you increase the inner loop by subdividing. I
actually think that it is faster

foreach line
   for proximal gridpoints
      do work

where proximal is at most 8 grid units away. The rest is truncated
(clamped) at 8. I am choosing 8 because this is probably enough (or
not).

As you walk along the (subdivided) path, you can optimize and update
distance for the points ahead (along the line) only, without looking
behind as those distances increase. The sign is tentative and flips on
updating the grid depending if it is to the right or to the left of
the line. You sort of sweep the grid proximal to the path. There is
another optimization possible, as you move along the subdivided curve,
you can only update grid points in a "orthogonal/normal" sector
roughly the size of the small turn corner, which is rather small.

Does it make sense?

Alexei