Re: Logging Library-GSOC

[Priyesh kumar]

Hi Guys,

> *I do like that notation style ;)  Apart from that I for sure have not
used it on Windows;  don't worry about that either and thanks for
double-checking! :)*
Thanks for responding to my concerns...

>* As you are now moving into the implementation phase of your project I
would quickly like to recall my message from about a month ago: *
*> https://lists.nongnu.org/archive/html/freetype -
devel/2020-05/msg00165.html
.
Don't worry about exact naming and we might need more functions and/or more
arguments but outlining the  > general idea:  I would very much appreciate
it if we could find a way to wrap FT logging into a public interface that
works something along these lines.  So basically there's a default log  *
*> callback implemented internally that listens to environment variables
(and/or other, more dynamic inputs) and then there's a way to overwrite
this callback from the outside by providing (a)  > custom function(s).  All
details are obviously up for discussion :)*
Will work on it and respond...

Also I have updated the progress report for 3rd week @ here

Sorry, for replying this late...

Thanks,
Priyesh


On Sat, Jun 20, 2020 at 5:03 PM  wrote:

> Hi Priesh,
>
> >> In previous mails, Armin suggested to move some of the FreeType's
> >> logging functionality to the external logger but according to my
> >> analysis, none of the external logging libraries that I have
> >> explored exactly matches the logging architecture of FreeType
> >> (i.e. logging based on debug level of components and debug levels of
> >> trace calls).  According to me, this is not possible with dlg
> >> library [...]
> >
> > This is not a problem at all.
>
> Don't worry about that -- I was just thinking out loud about things we
> could do :)
>
> > (For Armin){
> > I have looked into log4c, [...] but I am not sure about it on windows
> [...]
> > }
>
> I do like that notation style ;)  Apart from that I for sure have not used
> it on Windows;  don't worry about that either and thanks for
> double-checking! :)
>
> As you are now moving into the implementation phase of your project I
> would quickly like to recall my message from about a month ago:
> https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00165.html.
> Don't worry about exact naming and we might need more functions and/or more
> arguments but outlining the general idea:  I would very much appreciate it
> if we could find a way to wrap FT logging into a public interface that
> works something along these lines.  So basically there's a default log
> callback implemented internally that listens to environment variables
> (and/or other, more dynamic inputs) and then there's a way to overwrite
> this callback from the outside by providing (a) custom function(s).  All
> details are obviously up for discussion :)
>
>

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

[Alexei Podtelezhnikov]

On Sat, Jun 20, 2020 at 6:32 PM Behdad Esfahbod  wrote:
> Systems without an FPU are vastly less common than they were 20 years ago.  
> They still exist, and is a defendable position to want FreeType to continue 
> to work on those systems, however:
>
>   - Compilers and kernels have stepped up to provide floating-point emulation 
> libraries which work transparently to the client code.  That is, introducing 
> limited use of float in FreeType is by no means an impediment to those 
> building the library for systems without FPU.  Even if that was not true, the 
> SDF module can be easily disabled,

Behdad,

The FT_Fixed underflows and overflows, which are definitely easier to
trigger, makes you think about degenerate cases in your logic and
equations. This is a huge benefit, not an obstacle. In the case of SDF
the distance always exists and is finite. Once the degenerate case is
identified using FT_Fixed, it is better to solve it using an
alternative formula or method, which always exists and is usually
simpler. This will make the code more stable and robust. IMHO, this
discipline makes FreeType indestructible.

I would love to see GPU, FPU, SIMD, compiler features, etc...
Unfortunately, there is maintenance cost associated with it. Just two
days ago 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=d924c5cf7e5554b22f7edfcb9e98670c4c02c3f0
and that was your contribution but the burden of fixing is on Werner.

It should have been easy to blow FreeType from the face of the Earth
with a faster GPU or SIMD rasterizer or using GPU, but for some reason
for 20 years nobody dared.

Alexei

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

[Anuj Verma]

Hello Behdad,

> I have.  In 2018 Nicolas Rougier and I presented a mini-course at
SIGGRAPH that covered all the SDF-based experiments of the past 10 / 15
years.
> If you haven't reviewed those, I suggest you do.  Unfortunately there's
no video and the slides are low resolution:
>
>
https://www.slideshare.net/NicolasRougier1/siggraph-2018-digital-typography
>
> In particular, I advise that you read the 2018-Langyel paper, which is
what's in sluglibrary.com:
>
>  http://www.terathon.com/i3d2018_lengyel.pdf
>
> Because if you follow my line of reasoning in my previous messages and
the rest of this message, I'm advising that you implement what basically
will be Lengyel's algorithm on the CPU.

I looked at the SIGGRAPH slides, it is interesting. Thanks for sharing.
I will read the Lengyel paper and will let you know.

> I thought about that a lot and did some research. This is a good summary:
>
>
https://math.stackexchange.com/questions/2432348/what-is-stopping-criteria-for-newtons-method/2433475#2433475
>
> Basically, if the solution is pulled out of [0,1] range, you can clamp
them.  If they keep pulling out again right after clamping, you can
discard.
> That post also suggests that what you are seeing was caused by your
fixed-point limitations.  Were you testing with float or fixed?:

I was testing it with fixed, I will again test it with floats and let you
know. Thanks for sharing the link.

>> * I've convinced myself, but probably can't be proved, that MAX_DIVISIONS=2
> is enough for always finding the closest point.
> >> That would speed up significantly.
>
> > It will certainly speed up the process a lot. But in the current
> implementation here are the results:
> > A) MAX_DIVISIONS=2 : https://i.imgur.com/B9Q8Kpa.png
> > B) MAX_DIVISIONS=4 : https://i.imgur.com/1sbl9MP.png
> > Maybe if I don't break out when the factor falls outside [0.0, 1.0],
> MAX_DIVISIONS=2 might work.
> > But currently there are issues when using MAX_DIVISIONS=2.
>

[note the two images above are constructed using fixed point, I will
specify this from now on]

> I take that back.  Moreover, I'm convinced with 4 you still get very
noticeable artefacts with correctly-constructed fonts.

> When I was thinking through it last time I was mistakenly thinking that
there are three roots, whereas there are five.  Moreover, the positions of
the roots
> can be arbitrarily close to each other. Moreover, there's no fast
criteria to know the quality of the Raphson output or know when to
terminate.  As such, I
> believe the method cannot be made correct (as in not producing artefacts)
and fast at the same time.

If you are talking about the artifact at the corners, it is again caused
only while using fixed-point. Moreover, it also happens
in simple contours with only line segments (https://i.imgur.com/MZsNeHJ.png
- uses fixed). I will try to fix this for fixed-points.
Here is an SDF using floats: https://i.imgur.com/QSGCoIj.png - uses floats
and Raphson

> So I go back to my suggestion earlier on: that you convert cubics to a
series of quadratics.  Note how that conversion needs to be done once only,
not per pixel.
>
> For the conversion I suggest lifting the core ideas from cu2qu:
>
>   https://github.com/googlefonts/cu2qu/issues/10
>
> ideally withe cusp issue handled:
>
>  https://github.com/googlefonts/cu2qu/issues/6

I will try to optimize Newton's method (will also try to remove artifacts)
and will also check the performance of converting cubic to quadratic, then
we can finally decide what to use.

> I understand why you are doing it.  I believe it's not necessary.  Let me
try again.  See if you can prove the following for yourself.
> I have proved it and can share.  (Only if we had a mathematician around
;)).
>
> Lemma: if the closest point on curve [0,1] is to the endpoint at t=1 and
the cubic equation has no real root at t=1, the cubic equation must have at
least one real root at some t > 1.
> Similarly, if the closest point on curve [0,1] is to the endpoint at t=0
and the cubic equation has no real root at t=0, the cubic equation must
have at least one real root at some t > 1.
>
> As such, you just need to compute all real roots, clamp them to [0,1] and
remove duplicates.

[there is a typo, it should be t < 1 at the last point]

I tried to use this and it works exactly the same as before but faster.
Thanks for that.
I can't quite figure out the proof, here is what I think:
The cubic equation here is used to find the perpendicular to the curve.
Now, if we forget about the range [0, 1] the perpendicular can be anywhere.
Moreover, the slope of curve is given by a linear equation ( y = mx + c ),
that means it varies from [-90, 90] (tan(x) varies from [-inf, inf]: this
is also the reason why there has to be at least one real
root/perpendicular).
So, if we extend the endpoints we will get a perpendicular somewhere down
the
line, but I can't figure out why it is at t > 1 if the nearest point is at
t = 1
and vice versa. It will be great if 

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

[Werner LEMBERG]

> One more thing, shouldn't it be a `minmum level of warnings.' ?
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftgrays.c#n441

No, I don't think so.  I interpret the text as that you can switch on
the maximum number of compiler warnings by suppressing warning 4324.


Werner

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

[Anuj Verma]

 > *I agree with Behdad.  Using functions, even for stuff that gets called*
> *only once, greatly enhances readability of code, among other things.*
> *So please proceed as you plan :-)*

Yes, I will. Thanks

>> *I strongly advise that you reconsider this.*
>
> *We discussed that already, didn't we?*

Yes, I will summarize. For now I will be using fixed points. And later
I will write code specific to platforms which support floats and SIMD.
I hope that is okay.

> *I beg to differ.  A GSoC project is not only to implement one thing in*
> *one way.  It is an opportunity to learn.  Anuj is now seeing both*
> *sides of the fixed-point mathematics medal, so to say; as soon as he*
> *will have mastered the project he knows *exactly* when to use it and*
>
*when to avoid. *

Before this project I never knew there was something like fixed-point. I
knew that at the end of the day floats are also stored in bit array, but
I didn't know that something like this is used until I started working
on this project.
At first it was a bit frustrating to work with them but I have gotten
used to them now. So yeah it has been a good learning opportunity :)

One more thing, shouldn't it be a `minmum level of warnings.' ?
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftgrays.c#n441

Thanks,
Anuj