Re: [Freetype-devel] Re: GSOC - Distance Fields
On Sun, Jun 28, 2020 at 10:18 AM Anuj Verma wrote: > Apart from that, I thought about another optimization: > Smooth rasterizer is ultra fast, it only takes a few nano- > seconds to render. So we can embolden the outline by > spread, render it with the smooth or monochrome rasterizer > and that will give us all the points that we need to check. It > can pair up well with the bounding box method. Unfortunately, the emboldening algorithm has flaws... The stroker is probably a bit more reliable but is much slower too. The smooth renderer performance is a good benchmark to aspire to and I think that the SDF renderer can be within reach. The distance to a line is a cross product divided by the line length ignoring the distances to the ends for a moment. The division by the length is the same for all grid points in the neighborhood so it can be reused as inverse length. The cross products are also interesting: they turn out to be incremental from grid to grid point. Combining the two facts, it is super fast to fill the neighborhood of a line using a single division. Now you just have to deal with the ends trivially. That is why I think that ultimately dividing the curves will win and the performance will be comparable to the smooth renderer. Best, Alexei
Re: [Freetype-devel] Re: GSOC - Distance Fields
Hello Alexei, > Do you know from your floating point version if q3 or r2 is larger > when this happens? From your description it sounds like q3 is still > larger than r2. In this specific case where q3 becomes 0, r2 is always greater than q3. But generally q3 can be greater than r2 in some cubic equation. > In this case, if (r2 == 0) is missing here: I just checked and r2 can also cause underflow, so yeah I should check r2 == 0. But, this check only reduce the error it does not eliminate it. I even checked increasing the precision but it still happens, and increasing precision also creates a risk of overflow. So, I might have to think of something else. Apart from that, I thought about another optimization: Smooth rasterizer is ultra fast, it only takes a few nano- seconds to render. So we can embolden the outline by spread, render it with the smooth or monochrome rasterizer and that will give us all the points that we need to check. It can pair up well with the bounding box method. Thanks, Anuj
Re: [Freetype-devel] Re: GSOC - Distance Fields
Hi Anuj, Thanks for the reference: > This happens because of underflow, if you check the `solve_cubic_equation' > function > (https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L490) > there is a term `q3' which is cube of term `q'. So, in cases where is `q' is > pretty small `q3' becomes zero. And later in the algorithm we have to take > the `cube_root' of the term (q3 + r2) to find the final roots. Now because of > underflow the impact of `q' on the final output is zero. That is why the roots > davaiate and we get a wrong value. In some cases the deviation is quite high. Do you know from your floating point version if q3 or r2 is larger when this happens? From your description it sounds like q3 is still larger than r2. In this case, if (r2 == 0) is missing here: https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L577 Alexei
