freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexei Podtelezhnikov
Subject: Re: [Freetype-devel] Re: GSOC - Distance Fields
Date: Tue, 23 Jun 2020 00:23:01 -0400

Hi Anuj,

Good job again!

> > 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).
>
> I tried this method, and yes it is very (probably a lot) faster than checking 
> all the
> grid points. I did not check the performance but now I can generate 512 pixel 
> size
> glyphs within a click. However there are a few issues:
> * First, subdividing creates wrong results. I did not try subdividing bezier 
> curves. For
>   start I simply divided the line segments into 8 segments and I generated 
> SDF in the 8x8
>   neighborhood of those segments, but it results in wrong distances at some 
> points. I don't
>   know the exact reason for this so I will try to find it out.

You probably mean the slight "pulsing" inside. You are right, it
should not happen. It might be the same effect as the one apparent on
the miter line, or I am just seeing things.

> * Second, checking the 8x8 neighborhood causes hard edges. 
> (https://i.imgur.com/SunxGGU.png)

The 8x8 neighborhood has larger distances diagonally than vertically
or horizontally so they (like all distances) have to be clamped
accordingly. You should probably also preset (memset) the grid to the
same cutoff value with appropriate sign for the outside. Keep in mind
that orientations are different for TrueType and Type1/CFF.

>
> > The sign is tentative and flips on
> > updating the grid depending if it is to the right or to the left of
> > the line.
>
> * It is correct to determine the sign this way, but it only determines the 
> sign of the
>   pixels that we are actually checking. There are still points left whose 
> sign is to
>   be determined. We can clamp them to 8, but still the sign has to be 
> determined. I think
>   we can use this for that: 
> https://skia.googlesource.com/skia/+/refs/heads/master/src/gpu/GrDistanceFieldGenFromVector.cpp#23

Even if you preset the field to an appropriately signed cutoff, there
might still be unvisited inside regions of opposite signs. Those can
be found by one pass over looking for large discontinuities, easily
fixable by flipping the sign.

> Lastly, instead of checking the 8x8 neighborhood of the line segments, I 
> calculated the
> bounding box of the line, increased it by 8 in the x and y direction and used 
> that to
> calculate the distances. It is still very fast and doesn't result in that 
> hard edge (https://i.imgur.com/24Rz8eV.png).
> We can even align the bounding box along the line and create a pretty tight 
> space. I
> think it is worth giving it a try as well.

Sure, I like it. This is a good test if splitting is worth anything.

Thank you for your hard work!
Alexei



reply via email to

[Prev in Thread] Current Thread [Next in Thread]