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: Anuj Verma
Subject: Re: [Freetype-devel] Re: GSOC - Distance Fields
Date: Mon, 15 Jun 2020 12:22:06 +0530


Hello Werner,

Thanks for checking the code and for your comments.

Did you miss the last two mails from Alexei and me?
I missed a few mails a few days ago for no reason and
even got a few duplicate mails.

> I think he means that the code must be optimized as much as possible
> to get fast rendering. In particular, it is important to find and
> eliminate hotspots.

Yes, he wanted to check if it's worth splitting the curves into line
segments to get better performance without losing much details. I did
a performance analysis and have attached it in the previous mail.

> Some comments to your code.
> * What does line 38 do?

There is no use for that. It was just me checking the accuracy of the
output. I forgot to remove that before committing.

> * Function `get_min_conour` should probably be called
>   `get_min_contour`.  Otherwise please explain in a comment what
>   'conour' means.

Another typo, I did fix it in the header file but forgot in the
source file. Thanks for pointing that out.

> * Have you thought about iterative solutions to get the cubic roots
>   necessary for the quadratic case?  Maybe this would be faster.

This can be faster because we only need to find the roots within
the range [0.0, 1.0]. So, I will implement an iterative solution
and see how it goes.

> * Maybe there is a mathematical approximation to solving the
>   fifth-grade polynomial.  I don't mean a better root-finding
>   algorithm but a simpler representation of the curves so that we can
>   avoid a fifth-grade polynomial altogether.  The same holds for the
>   third-grade equation, of course.

I am definitely avoiding the fifth-degree polynomial. If you look the commit
(https://github.com/preversewharf45/freetype2-sdf/blob/5322b28305b3b1a2d45ef68a057fe97efe113cbb/src/sdfgen.c#L523)
I was actually solving the fifth-degree polynomial, later I decided to remove
because it was huge and slow. Now I bisect the curve in four parts and
use newton's iteration to find the closest point on the curve.
So to avoid the third-degree polynomial I can use the exact same method
that I use for cubic-curves, but I checked the performance and it's actually
faster to simply solve the polynomial in case of conic-curves. (in case you
missed the mail: https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00095.html)

> PS: Did you have a look at Behdad's `GLyphy` implementation?

Yes, I did check out `GLyphy'. He converts bezier curves to arcs, but I'm
not sure how he does it. Perhaps he is using this algorithm.
(https://github.com/preversewharf45/papers/blob/master/Cubic%20curves%20to%20Circular%20arcs.pdf)

Behdad, It would be great if you tell me more about your algorithm and if
it is faster to convert bezier to arcs and find the signed distance.

Thanks,
Anuj

reply via email to

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