On Thu, Jun 18, 2020 at 8:01 AM Anuj Verma <an...@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