Hello Werner,
> IMHO, in FreeType, SIMD support is something to be done in addition,
> not as a replacement. Since Anuj makes quick progress I suggest that
> he first concentrates on the fixed-float route. If there is some time
> left we should check how SIMD can be implemented.
Just to
Hello Alexei,
> Each curved segment has a large number [...]
I guess this is similar to the Euclidean distance transform algorithm.
http://webstaff.itn.liu.se/~stegu/JFA/Danielsson.pdf
As I said before I will not leave out this option, I will try to implement
this
and then we can compare the
I forgot to add the gprof output. This is the final mail for sure.
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls us/call us/call name
35.67 1.02 1.02 14600 0.01 0.01
Hello Behdad,
> First, let me congratulate you. This is a very thorough and impressive
piece of work for such a short time period.
Thank you for that. Viktor's paper did help me a lot while writing the
code. I guess you have already read his paper,
but in case anyone is interested in reading it
> Also I'm surprised that you haven't put the code get_min_distance code
for each edge type into a function.
> Would you prefer that I comment re these on github?
I don't think that will be necessary. I will fix that while adding in
FreeType. That repository is just for
testing and I might delete
> After you do all this, you will realize that the speed is still a
concern. Don't do bounding-box check.
> Classic way to do after is to split into a coarse grid and for each cell
find all edges that may be relevant.
> Then for pixels in each cell only process those edges. This is what
GLyphy
On Tue, Jun 16, 2020 at 9:50 AM Werner LEMBERG wrote:
> >>> - Your handling of two edges meeting at a corner is solid. That's
> >>> exactly what we do in GLyphy. However, I'm also now convinced
> >>> that there is no way to produce SDF from contours that might
> >>> overlap. Imagine a
For SIMD, I studied what's available last year for HarfBuzz. I documented
what I found here:
https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh
If you use floats internally and fill in the distances, then you can do
SIMD passes at the end to do sqrt, clamping, and other things to
Hi Anuj,
First, let me congratulate you. This is a very thorough and impressive
piece of work for such a short time period. I read your code over a week
ago but couldn't sit down and type this. I see there has been lots of
progress since. I'll just summarize:
- I highly suggest you stick to
On Tue, Jun 16, 2020 at 11:02 AM Werner LEMBERG wrote:
>
> > For SIMD, I studied what's available last year for HarfBuzz. I
> > documented what I found here:
> >
> > https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh
>
> Thanks for the link, it's an interesting read.
>
> > If you
On Mon, Jun 15, 2020 at 9:47 AM Alexei Podtelezhnikov
wrote:
> On Mon, Jun 15, 2020 at 11:03 AM Anuj Verma wrote:
> >>
> > > For linear segments, it will save more than 90% according to your
> > > table. Then you will see that splitting Bezier curves is not such a
> > > bad option. In general,
Also I'm surprised that you haven't put the code get_min_distance code for
each edge type into a function. Would you prefer that I comment re these
on github?
On Tue, Jun 16, 2020 at 8:53 AM Behdad Esfahbod wrote:
> Oh, I forgot:
>
> After you do all this, you will realize that the speed is
Anuj,
Each curved segment has a large number of neighboring grid points.
each of which has a unique nearest projection on the curve. The curve
is naturally sampled by this projection points a very large number of
times and quite uniformly. Therefore, why not divide the curve into a
large number
> For SIMD, I studied what's available last year for HarfBuzz. I
> documented what I found here:
>
> https://github.com/harfbuzz/harfbuzz/blob/simd/src/hb-simd.hh
Thanks for the link, it's an interesting read.
> If you use floats internally and fill in the distances, then you can
> do SIMD
>>> - Your handling of two edges meeting at a corner is solid. That's
>>> exactly what we do in GLyphy. However, I'm also now convinced
>>> that there is no way to produce SDF from contours that might
>>> overlap. Imagine a "+" sign that is two straight contours. You
>>> cannot find
On Tue, Jun 16, 2020 at 9:49 AM Alexei Podtelezhnikov
wrote:
> Anuj,
>
> Each curved segment has a large number of neighboring grid points.
> each of which has a unique nearest projection on the curve. The curve
> is naturally sampled by this projection points a very large number of
> times and
Oh, I forgot:
After you do all this, you will realize that the speed is still a concern.
Don't do bounding-box check. Classic way to do after is to split into a
coarse grid and for each cell find all edges that may be relevant. Then
for pixels in each cell only process those edges. This is
Hi guys,
(For Armin){
I have looked into log4c, no doubt it is a powerful logging library and we
could use some of it's features to share some logging functionality from
FreeType,
but I am not sure about it on windows as I am having a hard time compiling
it on windows and also I think the
18 matches
Mail list logo
