Re: I'm back

[Behdad Esfahbod]

Hi David,

I've been meaning to reply to your request but the list of things I wanted
to communicate kept growing exponentially and so I have not been able to
say.

But here, from a technical perspective this is my biggest issue, which you
can also see as a roadmap:

  https://gitlab.gnome.org/GNOME/pango/-/issues/404#note_851881

I will keep trying to comment on the two GSoC projects, and eventually get
to write about the health of the freetype as a community project.

Cheers,
behdad

On Fri, Apr 24, 2020 at 1:03 PM David Turner  wrote:

> Hello freetype-devel@ list members,
>
> It's been a very very long time, but I have some free time in the coming
> weeks to work on FreeType. Werner invited me to write a small announcement
> here and I'm currently looking at the official bugs list.
>
> I'd like to know what are, in your opinion, the most pressing issues to
> work on at that point?
>
> Apart from that, I had the following things in mind:
>
> - Improving / refactoring the build system a little. E.g. it should be
> possible to simplify the rules.mk/module.mk files considerably, and
> auto-generate most of the Makefiles / Jamfiles / CMakefiles from a single
> source of truth (exact format to be defined), at least the parts that deal
> with the headers / sources / configuration headers and the module
> dependencies.
>
> - Improve testing (unit and regression tests to be exact) There are lots
> of possibilities here, and it will probably better to do this in small
> incremental steps.
>
> Voila, I'd be happy to read your suggestions, Happy to be here.
>
> - David Turner
>


-- 
behdad
http://behdad.org/

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have updated the progress report for this week @ here
> 
> It contains a brief description of all the useful APIs provided by
> dlg

Thanks, looks promising.  If you are going to import the 'dlg' files I
suggest that you put the necessary files into

  src/dlg

(in your personal branch of FreeType's git repository).


Werner

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

[Werner LEMBERG]

> One more thing.  I think the OpenGL demo is not good for everyone to
> test, so I will working on a demo similar to 'ftview' in my spare
> time.

Great!


Werner

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

[Anuj Verma]

One more thing. I think the OpenGL demo is not
good for everyone to test, so I will working on a
demo similar to 'ftview' in my spare time.

On Sat, Jun 27, 2020, 8:21 PM Anuj Verma  wrote:

>
> >> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
> >> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
> >> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
> >
> > [for subdivision I equally divided the curve into 16 parts]
> > This is a tie between B and C because you can still find some
> > interesting optimizations
>
> Yes. For now I'll integrate the A method and then start optimizing, and I
> will
> also use some better tools that Vincent suggested for profiling.
>
> > There is another reason why subdividing cound faster: the bounding box
> > of a line is larger than two bounding boxes of its halfs, not
> > considering the padding (spread). However, 16 is too arbitrary. In
> > fact, in our antialiased renderer we divide until the curve deviates
> > from the line no more than 1/8th or a pixel, which could be more or
> > less than 16 depending on the size of the curve and its shape.
>
> I used 16 because It doesn't create jagged edges and looks exactly
> as method A. I believe the smooth renderer uses de Casteljau algorithm
> so I'll use that to subdivide.
>
> >> However, it is not always faster than the bounding box check, If we
> increase the
> >> spread to 16, then it gets a bit slower, because while checking the
> proximity the
> >> number of duplicate checks increases. But I believe that it can be
> avoided by
> >> only checking the grid points that are perpendicular to the line
> segment as you
> >> said in a previous mail.
> >
> > This sort of optimizations can be quite complex to implement though,
> > which might defeat the purpose.
>
> I thought about this, we can align the bounding box in the direction of
> the line,
> that way all the points inside the bounding box will be perpendicular, the
> only
> problem is to actually find the points inside the box, which can be a bit
> tricky.
>
> > Do you understand why the underflow happens? Is it because the curve
> > arches around the point and there exist multiple solutions, perhaps
> > almost an infinite number of solutions? Does the equation with all
> > coefficients substituted become quadratic or linear and you can solve
> > it differently? Your method is still very good.
>
> I explained this to Werner a while ago in this message:
> https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00127.html
> It happens when there is exactly one root of the cubic equiation and
> the curve gets really close so the point. I'm almost sure that It can be
> avoided by increasing the precision, but I haven't tried it yet.
>
> >> Finally, my opinion about subdividing is changed and I say that it's
> definitely worth
> >> subdividing the curve as it increases performance. But, as I said if
> the spread is
> >> more than 8 then it gets slower as of now without any optimizations and
> I still think
> >> we should keep the spread at least 32. So, to clarify weather 8 or 32
> is a good number
> >
> > I wonder if there is a way to test this using some SDF demo tool...
>
> I currently use an OpenGL demo, and in that even a spread of 2
> is enough to draw perfectly, so 8 would be plenty. I just think that
> 32 gives a good range. On the other hand 64 is overkill and it almost
> looks like a circle above 64.
> Either way the subdivision method will work even with 32, so there is
> no problem with the spread now. Moreover what is your opinion about
> implementing both the methods ?
>
> > But for 4 is only 2 bits...I remember you decided to use FT_F2Dot14.
> > What is the correct way of presenting SDF to a client? What is the
> > common practice?
>
> That will have to be changed now, I previously thought of normalizing the
> values, but that is not a good idea. Now, I'm thinking of using something
> like 8.8 and another option of 3.5. That way if the user has low memory
> they can use the 8bit version.
> In skia Jim uses 3.5 so that might be good. I'm still not sure about the
> format
> but that can easily be changed.
>
> Thanks,
> Anuj
>

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

[Anuj Verma]

>> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
>> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
>> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
>
> [for subdivision I equally divided the curve into 16 parts]
> This is a tie between B and C because you can still find some
> interesting optimizations

Yes. For now I'll integrate the A method and then start optimizing, and I
will
also use some better tools that Vincent suggested for profiling.

> There is another reason why subdividing cound faster: the bounding box
> of a line is larger than two bounding boxes of its halfs, not
> considering the padding (spread). However, 16 is too arbitrary. In
> fact, in our antialiased renderer we divide until the curve deviates
> from the line no more than 1/8th or a pixel, which could be more or
> less than 16 depending on the size of the curve and its shape.

I used 16 because It doesn't create jagged edges and looks exactly
as method A. I believe the smooth renderer uses de Casteljau algorithm
so I'll use that to subdivide.

>> However, it is not always faster than the bounding box check, If we
increase the
>> spread to 16, then it gets a bit slower, because while checking the
proximity the
>> number of duplicate checks increases. But I believe that it can be
avoided by
>> only checking the grid points that are perpendicular to the line segment
as you
>> said in a previous mail.
>
> This sort of optimizations can be quite complex to implement though,
> which might defeat the purpose.

I thought about this, we can align the bounding box in the direction of the
line,
that way all the points inside the bounding box will be perpendicular, the
only
problem is to actually find the points inside the box, which can be a bit
tricky.

> Do you understand why the underflow happens? Is it because the curve
> arches around the point and there exist multiple solutions, perhaps
> almost an infinite number of solutions? Does the equation with all
> coefficients substituted become quadratic or linear and you can solve
> it differently? Your method is still very good.

I explained this to Werner a while ago in this message:
https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00127.html
It happens when there is exactly one root of the cubic equiation and
the curve gets really close so the point. I'm almost sure that It can be
avoided by increasing the precision, but I haven't tried it yet.

>> Finally, my opinion about subdividing is changed and I say that it's
definitely worth
>> subdividing the curve as it increases performance. But, as I said if the
spread is
>> more than 8 then it gets slower as of now without any optimizations and
I still think
>> we should keep the spread at least 32. So, to clarify weather 8 or 32 is
a good number
>
> I wonder if there is a way to test this using some SDF demo tool...

I currently use an OpenGL demo, and in that even a spread of 2
is enough to draw perfectly, so 8 would be plenty. I just think that
32 gives a good range. On the other hand 64 is overkill and it almost
looks like a circle above 64.
Either way the subdivision method will work even with 32, so there is
no problem with the spread now. Moreover what is your opinion about
implementing both the methods ?

> But for 4 is only 2 bits...I remember you decided to use FT_F2Dot14.
> What is the correct way of presenting SDF to a client? What is the
> common practice?

That will have to be changed now, I previously thought of normalizing the
values, but that is not a good idea. Now, I'm thinking of using something
like 8.8 and another option of 3.5. That way if the user has low memory
they can use the 8bit version.
In skia Jim uses 3.5 so that might be good. I'm still not sure about the
format
but that can easily be changed.

Thanks,
Anuj

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

[Alexei Podtelezhnikov]

H Anuj,

On Fri, Jun 26, 2020 at 8:16 AM Anuj Verma  wrote:

> A) Checking all grid points:15.43 seconds (~154ms per glyph average)
> B) Bounding Box check: 0.898 seconds (~8.98ms per glyph average)
> C) Subdivision method : 0.665 seconds (~6.65ms per glyph average)
>
> [for subdivision I equally divided the curve into 16 parts]

This is a tie between B and C because you can still find some
interesting optimizations

> Yes, the subdivision method is the fastest, I was not expecting this to happen
> considering it increases the number of duplicate checks and also increases the
> number of lines. Anyway, it is faster because of obvious reasons (we don't 
> have
> to `solve_cubic_equation' which is the slowest part of the entire process).

There is another reason why subdividing cound faster: the bounding box
of a line is larger than two bounding boxes of its halfs, not
considering the padding (spread). However, 16 is too arbitrary. In
fact, in our antialiased renderer we divide until the curve deviates
from the line no more than 1/8th or a pixel, which could be more or
less than 16 depending on the size of the curve and its shape.

> However, it is not always faster than the bounding box check, If we increase 
> the
> spread to 16, then it gets a bit slower, because while checking the proximity 
> the
> number of duplicate checks increases. But I believe that it can be avoided by
> only checking the grid points that are perpendicular to the line segment as 
> you
> said in a previous mail.

This sort of optimizations can be quite complex to implement though,
which might defeat the purpose.

> Moreover the subdivision method gets rid of underflow issues that were caused
> while solving the cubic equation.

Do you understand why the underflow happens? Is it because the curve
arches around the point and there exist multiple solutions, perhaps
almost an infinite number of solutions? Does the equation with all
coefficients substituted become quadratic or linear and you can solve
it differently? Your method is still very good.

> Finally, my opinion about subdividing is changed and I say that it's 
> definitely worth
> subdividing the curve as it increases performance. But, as I said if the 
> spread is
> more than 8 then it gets slower as of now without any optimizations and I 
> still think
> we should keep the spread at least 32. So, to clarify weather 8 or 32 is a 
> good number

I wonder if there is a way to test this using some SDF demo tool...

> I'm CCing Jim, as he uses SDF in skia he will be able to tell whether 8 is 
> enough.

Jim said 4. It is a good idea to have it adjustable. The glyph ppem
size defines the grid resolution and the spread/padding defines the
SDF radius. Both numbers are sufficient to allocate appropriate memory
for each glyph depending on its CBox.

But for 4 is only 2 bits...I remember you decided to use FT_F2Dot14.
What is the correct way of presenting SDF to a client? What is the
common practice?

Regards,
Alexei

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

[Anuj Verma]

> I assume spread means maximum distance.

Yes.

> We use a spread of 4, so 8 would be plenty. We use 4 mainly to keep the
glyph sizes under control,
> because a larger spread means a larger pad of texels around each glyph to
make use of that information.

So I guess 8 is enough for now. And btw it will be adjustable.

Thanks for the info,
Anuj

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,
I have updated the progress report for this week @ here

It contains a brief description of all the useful APIs provided by dlg
Please look at the report...
Thanks,
Priyesh

On Thu, Jun 25, 2020 at 1:26 PM Werner LEMBERG  wrote:

>
> > [...] Therefore, according to me if you are concerned about the
> > additional code that we need to add along with using dlg, it would
> > be much less than the code if we develop a logger inside FreeType
> > with all of the above the requirements and support on different
> > platforms.
>
> OK.
>
> > I would try to document all the dlg's features that I am going to
> > use along with how I am going to use them in week 4 and week 5
> > progress reports.
>
> Looks good, thanks!
>
>
> Werner
>