>> Thanks, too. What do you think about integrating this into (at
>> least) `ftview`?
>
> Yes, it can be integrated into the existing demo programs, however I
> think it should have a separate demo program because of the way SDF
> is rendered, it has a raw and reconstruction view as well as
>> Werner, Are you still interested in adding API to remove overlaps?
>
> Yes, I am.
Alright, I will start reading more about it after GSoC.
>> I have updated the demo to include the new algorithm to handle
>> overlaps. [...]
>
> Thanks, too. What do you think about integrating this into (at
> Werner, Are you still interested in adding API to remove overlaps?
Yes, I am.
> I watched the skia code and the video on how it's done in skia. I
> think it's doable, the only tricky part that I think is to find the
> intersecting point of contours, because they use a 4th degree
> polynomial
Hello Alexei, Werner,
>> I meant it all along but perhaps it is hard to do it on the fly. Ther
>> rules seem to be as follows:
>>
>> 1) Both outside (both positive), choose a smaller value
>> 2) Both inside (both negative), choose a smaller value as in (-5 < -4)
>> not by absolute value
>> 3) one
> I meant it all along but perhaps it is hard to do it on the fly. Ther
> rules seem to be as follows:
>
> 1) Both outside (both positive), choose a smaller value
> 2) Both inside (both negative), choose a smaller value as in (-5 < -4)
> not by absolute value
> 3) one inside one outside, choose a
> I.e. always choose a smaller value combining two contours so it seems
This might be oversimplified, but it is clear that the sign is
supposed to agree with the winding number and the priority of
distances should be defined by the fill rule.
On Fri, Aug 7, 2020 at 10:58 AM Anuj Verma wrote:
>
> > Yeah. We should basically think of overlaying or combining two
> > distance fields, generated independently one for each contour.
> > Has this been discussed in the literature?
>
> No, it has not been. That sounds interesting, thanks for the
> Yeah. We should basically think of overlaying or combining two
> distance fields, generated independently one for each contour.
> Has this been discussed in the literature?
No, it has not been. That sounds interesting, thanks for the idea.
I will think about it tomorrow, perhaps it might solve
On Fri, Aug 7, 2020 at 12:54 AM Anuj Verma wrote:
>
> Hello Alexei,
>
> > Can you describe discontinuities with the same sign if I overlook them?
>
> So, I found there are two types of discontinuities due to overlapping
> contours:
>
> A) Discontinuity in sign. (i.e. there is a sudden jump from
Hello Alexei,
> Can you describe discontinuities with the same sign if I overlook them?
So, I found there are two types of discontinuities due to overlapping
contours:
A) Discontinuity in sign. (i.e. there is a sudden jump from negative to
positive)
B) Discontinuity in distances. (i.e. the
Hi Anuj,
> > If I understand correctly, overlaps cause unexpected discontinuity in
> > SDF, which otherwise should not have any. I doubt that detecting and
> > removing contour overlaps is productive. I would rather deal with the
> > discontinuity directly. Perhaps there is a clever way to ignore
Hello Anuj,
> I have mostly completed the bitmap to SDF renderer (bsdf), there are
> only a few things remaining such as support for all pixel modes
> (currently it only work with FT_PIXEL_MODE_GRAY), and warnings etc.
Excellent, thanks!
> Next, I will be finishing the bsdf renderer and then
> Only FT_PIXEL_MODE_MONO is necessary to add. I do not understand how
> LCD or BGRA can be used for SDF; GRAY2 and GRAY4 are defunct.
It might be possible to convert LCD and BGRA to SDF, either using a single
channel or by converting them to grayscale, but yeah I don't think that
will be
Hi Anuj,
> I have mostly completed the bitmap to SDF renderer (bsdf), there
> are only a few things remaining such as support for all pixel
> modes (currently it only work with FT_PIXEL_MODE_GRAY),
Only FT_PIXEL_MODE_MONO is necessary to add. I do not understand how
LCD or BGRA can be used for
Hello Werner, Alexei,
I have mostly completed the bitmap to SDF renderer (bsdf), there
are only a few things remaining such as support for all pixel
modes (currently it only work with FT_PIXEL_MODE_GRAY),
and warnings etc. I did say before that the bitmap to SDF will require
less memory than the
> I have my college exams on 23rd and 24th this month, and as I
> haven't prepared for them yet, I would like to give a few days that
> are left and study for my exams.
Of course. I wish you success!
Werner
Hello Alexei, Werner,
I have my college exams on 23rd and 24th this month,
and as I haven't prepared for them yet, I would like to
give a few days that are left and study for my exams.
My last exam is on the 24th morning and after that I will
start doing the bitmap to SDF renderer which I think
Hi Anuj
> Which one do you think is better ? I prefer the second one i.e. adding
> another renderer within the `sdf' module. That way I can share some
> of the code, whereas creating another module will require me to
> rewrite everything.
Same module with two renderers as you described makes
>> * `FT_Lookup_Renderer' uses renderer format which is currently
>> `FT_GLYPH_FORMAT_OUTLINE' for the `sdf' module. How can
>>make it accept both outline and bitmap glyph format ?
>
> Regarding the second issue I think that you probably have to create a
> second renderer that shares most
> On Jul 16, 2020, at 00:42, Werner LEMBERG wrote:
>
>
>>> I would be less worried about FT_Property_Set if FreeType reserved
>>> the right to remove (ignore) or change properties when it is
>>> reasonable to do so, i.e. properties should not be considered a
>>> part of API.
>>
>> Does
>> I would be less worried about FT_Property_Set if FreeType reserved
>> the right to remove (ignore) or change properties when it is
>> reasonable to do so, i.e. properties should not be considered a
>> part of API.
>
> Does that mean I shouldn't use `FT_Property_Set' ? For some
> parameters
Hello Alexei,
> Ok to remove. This only optimizes mistaken calls to FT_Render_Glyph on
> bitmap fonts. A related question is whether we need FT_LOAD_TARGET_SDF
> for FT_Load_Glyph?
I don't think we need `FT_LOAD_TARGET_SDF', I much prefer loading it with
`FT_LOAD_DEFAULT' and then rendering it
Hi Anuj,
> > Alexei?
>
> Okay, I will probably only need to remove this case statement.
> ```
> case FT_GLYPH_FORMAT_BITMAP: /* already a bitmap, don't do anything */
>break;
> ```
Ok to remove. This only optimizes mistaken calls to FT_Render_Glyph on
bitmap fonts. A related question is
> I don't think this is an issue. For other rendering modes like LCD
> there are similar requirements, and platforms that are going to use
> SFDs certainly have plenty of memory. It would be nice, however, if
> you can add this constraint to the documentation, and, if possible,
> also add a
> I have updated the demo, added bilinear filtering, shape
> reconstruction and has all optimization modes which can be toggled.
> I have attached the new list of keys.
> (https://github.com/preversewharf45/ft2sdf-demo)
Looks excellent! Some items for the wishlist of `ftstd`:
* A help menu
> what about adding the other two methods (or one of them) and decide
> which one to choose with an option of the build system ? So one method
> fast build consume more memory than other one which is slower.
Yes, even I thought about that. We can also keep both the methods
and use
On Wed, Jul 15, 2020 at 7:14 AM Werner LEMBERG wrote:
>
>
> > I have added all the optimization modes to the module.
>
> Great, thanks!
>
> > By far the fastest method is to subdivide the curve into a number of
> > line segments. [...]
>
> OK. I'm glad that you took the time to implement the
> I have added all the optimization modes to the module.
Great, thanks!
> By far the fastest method is to subdivide the curve into a number of
> line segments. [...]
OK. I'm glad that you took the time to implement the various
algorithms so that we have such a comparison.
> The major
Hello All,
>> The basic sdf module is done, now that is left is to
>> optimize it, fix bugs etc. I will start by optimizing it.
>> I have decided to test three optimization method:
>> * Bounding box (BB)
>> * Subdivisions
>> * And also a coarse grid method that Behdad suggested.
I have added all
>> It's actually `--recurse-submodules`..
>
> I think they are both the same. They both do exactly the same thing
> for git clone. The ` --recurse-submodules` was added later to avoid
> confusion or something.
Interesting. The manpage of git 2.26.2 no longer contains a reference
to
>> You can check out the demo here:
>> https://github.com/preversewharf45/ft2sdf-demo The build process is
>> the same as ft2-demos. The freetype2 library is added as a submodule
>> so use --recursive.
>
> It's actually `--recurse-submodules`..
I think they are both the same. They both do
> You can check out the demo here:
> https://github.com/preversewharf45/ft2sdf-demo The build process is
> the same as ft2-demos. The freetype2 library is added as a submodule
> so use --recursive.
It's actually `--recurse-submodules`...
> And it only works properly on windows.
On GNU/Linux
> from a mathematical point of view only, you are doing a/64 + b/64
> (this line and also a bit above, which can be factorized like that :
> (a+b)/64. Maybe it is needed to divide first by 64 each term, i don't
> know, i just wanted to point this
I did this to avoid a few divisions and it works
On Sat, Jul 4, 2020 at 11:52 AM Werner LEMBERG wrote:
>
>
> > I have created the demo program, it can be used to view raw SDF
> > without any bilinear filtering and there is no way to reconstruct
> > fonts from SDF because again it doesn't have bilinear filtering. I
> > will add that soon.
>
>
> I have created the demo program, it can be used to view raw SDF
> without any bilinear filtering and there is no way to reconstruct
> fonts from SDF because again it doesn't have bilinear filtering. I
> will add that soon.
Thanks, will test soon.
> There is a pretty weird issue that I ran
Hello All,
>> 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!
I have created the demo program, it can be used to view raw SDF without
any bilinear filtering and there is no way to
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
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
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
> 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
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:
>> 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
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
> 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
I assume spread means maximum distance. 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. Unfortunately we have some pretty severe memory
On Fri, Jun 26, 2020 at 3:38 PM Anuj Verma wrote:
>
> > you also have DrMemory on Windows memory errors and leaks, and the
> > Visual Studio tools
> > (https://docs.microsoft.com/en-us/visualstudio/profiling/getting-started-with-performance-tools?view=vs-2017)
>
> That would be much more
> you also have DrMemory on Windows memory errors and leaks, and the
> Visual Studio tools
> (
https://docs.microsoft.com/en-us/visualstudio/profiling/getting-started-with-performance-tools?view=vs-2017
)
That would be much more convenient, I'll check these out.
Thanks,
Anuj
On Fri, Jun 26, 2020 at 3:01 PM Anuj Verma wrote:
>
> > have you tried to use valgrind's callgrind tool + kcachegrind ? It can
> > be very helpful
>
> No, I haven't. The problem is that I use windows for development and
> valgrind doesn't work on windows.So, switching back and forth makes
> the
> have you tried to use valgrind's callgrind tool + kcachegrind ? It can
> be very helpful
No, I haven't. The problem is that I use windows for development and
valgrind doesn't work on windows.So, switching back and forth makes
the process a bit tedious. I'll try to use it on WSL2.
Thanks for
On Fri, Jun 26, 2020 at 2:17 PM Anuj Verma wrote:
>
> Hello Alexei,
>
> I tried the subdivision method that you suggested. I'll start with the
> performance.
>
> I generated 100 glyphs with a pixel size of 256 and a spread of 8
>
> A) Checking all grid points:15.43 seconds (~154ms per glyph
Hello Alexei,
I tried the subdivision method that you suggested. I'll start with the
performance.
I generated 100 glyphs with a pixel size of 256 and a spread of 8
A) Checking all grid points:15.43 seconds (~154ms per glyph average)
B) Bounding Box check: 0.898 seconds (~8.98ms per glyph
Hello Werner,
> It's not clear to me what you want to achieve. Please elaborate.
For example If the user wants to enable multi-channel rendering which
gets rid of smooth corners, or to enable SIMD optimization. The simplest
example would be to enable overlapping contour support.
Anuj
> I added functionality to set renderer properties (namely the
> `spread' parameter). So, there is API for this `FT_Property_Set'
> and `FT_Property_Get'. Is there any similar API for setting the
> renderer specific modes which is defined by the
> `FT_Renderer_SetModeFunc' function, or do I
Hello Alexei,
> You probably mean the slight "pulsing" inside. You are right, it
> should not happen. It might be the same effect as the one apparent on
> the miter line, or I am just seeing things.
Yes, it's kind of like discontinuities in the distances. I'll share a
screenshot once I subdivide
Hi Anuj,
Good job again!
> > foreach line
> >for proximal gridpoints
> > do work
> >
> > where proximal is at most 8 grid units away. The rest is truncated
> > (clamped) at 8. I am choosing 8 because this is probably enough (or
> > not).
>
> I tried this method, and yes it is very
Hello Alexei,
> I actually think that it is faster
>
> foreach line
>for proximal gridpoints
> do work
>
> where proximal is at most 8 grid units away. The rest is truncated
> (clamped) at 8. I am choosing 8 because this is probably enough (or
> not).
I tried this method, and yes it is
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
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:
>
>
> 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.
> *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
> 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, [...]
Honestly, I think this an issue even today – just think of the
Internet of Things stuff, which demands
>>> 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
Hi Anuj,
On Tue, Jun 16, 2020 at 9:43 PM Anuj Verma wrote:
> 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
Werner!
On Wed, Jun 17, 2020 at 12:23 AM Werner LEMBERG wrote:
> > Also, why doesn't FreeType use floats? Is it just because of
> > platform which doesn't have floating point type?
>
> Yes. The original intention of FreeType was to provide support for
> embedded devices, which usually are
On Tue, Jun 16, 2020 at 9:54 PM Anuj Verma wrote:
>
> > 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
>
On Wed, Jun 17, 2020 at 7:22 PM Alexei Podtelezhnikov
wrote:
> Hi Anuj,
>
> Please let me finish my thoughts below...
>
> >> 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
On Sat, Jun 20, 2020 at 7:38 AM Anuj Verma wrote:
> Secondly, I did try subdividing the conic curves, for start I simply divided
> them into equal parts and used that to generate SDF. I saw that it require
> at least 32 divisions to produce a decent SDF, which in itself is quite slower
> than
Hello Alexei,
First thing, here is the result of all the curves after using square
distances:
A) Line Segment: ~0.10 microseconds
B) Conic Curves: ~0.75 microseconds
C) Cubic Curves: ~0.71 microseconds
For comparison, the previous result with `FT_Vector_Length':
A) Line Segment: ~0.32
> *Ok. This means that square-distance might need [...]*
I agree that 181 is enough in a typical SDF grid, and anyway
if we generate a 8bit SDF bitmap it won't be able to represent
more than 127 signed values.
And I also agree that closer distances are more important than
distant distances if
On Thu, Jun 18, 2020 at 8:01 AM Anuj Verma wrote:
>
> Hello Alexei,
>
> First, about using squared distances instead of `FT_Vector_Length', it
> is much faster to use squared distance. I tested it with a linear case and
> it comes around 0.114 microseconds, which is almost 65% faster than the
>
Hello Alexei,
First, about using squared distances instead of `FT_Vector_Length', it
is much faster to use squared distance. I tested it with linear case and
it comes around 0.114 microseconds, which is almost 65% faster than the
original time of ~0.32 microsecond. It isn't 90% faster because
Hi Anuj,
Please let me finish my thoughts below...
>> 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 these projection points a very large number of
>> times and quite
>> Please elaborate. It's not clear to me what you are referring to,
>> and what the problem is about.
>
> If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an
> ascii character `0' at pixel size 31, you can see that fixed point
> deviates from the actual path slightly, which does
> *Please elaborate. It's not clear to me what you are referring to, and*
> *what the problem is about.*
If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an ascii
character `0' at pixel size 31, you can see that fixed point deviates from
the actual path slightly, which does not
>> - I highly suggest you stick to float internally [...]
>
> I still think `float' is a better option for generating SDF,
> especially in lower resolution glyphs where fixed-point produces
> kind of straight lines instead of smooth curves (which is not
> noticable if you look at it briefly).
>> 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 clarify,
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 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
> 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
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
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
> 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
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
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
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
>>> - 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
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
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
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,
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 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 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, Bezier curves are used in graphics because it
> > is easy to split and
> 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 I received everything. It's only that sometimes I start
writing an e-mail and finish it hours later – in this case, Alexei has
answered
> 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, Bezier curves are used in graphics because it
> is easy to split and flatten them. I would be very surprised if
> distance fields
On Mon, Jun 15, 2020 at 9:06 AM Anuj Verma wrote:
>
> > Your profiling results indicate that a lot of time is spent
> > calculating distances. Perhaps, you can work with much faster
> > square-distances (they can be signed or signs stored separately) and
> > apply square root as a final
Replying to myself...
On Mon, Jun 15, 2020 at 8:11 AM Alexei Podtelezhnikov
wrote:
>
> Hi Anuj,
>
> > A) Line Segment: ~0.32 microseconds
> > B) Conic Bezier: ~1.08 microseconds
> > C) Cubic Bezier: ~1.25 microseconds
> >
>
> I am very surprised indeed. In the linear case, it is a trivial
>
Hi Anuj,
> A) Line Segment: ~0.32 microseconds
> B) Conic Bezier: ~1.08 microseconds
> C) Cubic Bezier: ~1.25 microseconds
>
I am very surprised indeed. In the linear case, it is a trivial
cross-product divided by the length of a segment, or the smaller of
two distances to the ends. There are no
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
1 - 100 of 136 matches
Mail list logo
