Re: fuzzing SDFs

*> Looks good! Please submit a Pull Request that Armin (and others) can > review. * Done! The fuzzer already found a bug in the renderer, I have attached a patch (diff.txt) to fix this (https://github.com/freetype/freetype2-testing/runs/3213214141). If you require a merge request instead, then

Re: fuzzing SDFs

*> Anuj, there is a lot of documentation in form of READMEs in this repository to hopefully give you a* *> high-level idea of how this thing is kind of put together. I reckon, a good entry point to probably this* *> script:

Re: A few questions about the new SDF render

> One more question: Do you have a recommended > font size for the SDF render? It will probably depend on the font, I’d say you won’t need more than 128, but I can be wrong. If you can, please build the demo program and see what works for you. Also, there are some imperfections in the ‘sdf’

Re: A few questions about the new SDF render

Hello Zhuyie, *> 1. From the comments in ftsdf.c, [...]* The implementation only supports single channel SDF. So the documentation for ` FT_RENDER_MODE_SDF ` is correct. Thanks though, the comment might need some editing. *> 2. Are there any tutorials about [...]* The output is a pretty basic

Re: new release?

* > I will push the positioning fix in a few hours and the moire pattern > is an artifact of our 16-level graphics blender. Looks really good > indeed, we only need to improve the speed. * Thanks for working on this. Since the output is only 8-bits now I might be able to use more bits for

Re: new release?

*> Can this be accomplished by a public macro? Probably not, because the* *> spread is not a public value, right? We can simply give an explicit* * > formula in the docs. * Yes, spread is not a public value. I have already added the pseudo code in `freetype.h` near `FT_RENDER_MODE_SDF`. I think

Re: new release?

@ -1,3 +1,32 @@ +2021-06-06 Anuj Verma + + [sdf] Use 8 bits for final SDF output instead of 16bits. + + Since 8bits is enough to represent SDF data we no longer require 16bits for this + purpose. Also, we now normalize the output data to use the entire 8bit

Re: new release?

Hello Alexei, *> Using signed char is a bit problematic because the FT_Bitmap buffer is > unsigned char. Going from signed to unsigned is well-defined, but > backwards is implementation-defined.* I'm assuming here that `FT_Bitmap` is simply a typeless buffer and the client can do a pointer

Re: new release?

nks, Anuj commit 623e66a142252b15ddfbd8f1c73874eae44a8f70 Author: Anuj Verma Date: Fri May 21 19:41:58 2021 +0530 [ftsdf] Synchronize with the change made in the `sdf` renderer. * src/ftsdf.c (draw): Change logic to utilize 8bit SDF instead of 16. diff --git a/src/ftsdf.c b/src/ftsdf.c index a638c3e

Re: new release?

Hello Werner, Alexei, Apologies for not replying earlier. We have already discussed 8 Bit SDF earlier and I agree that 8 Bits is enough for producing acceptable interpolation for rendering. Here is the mail for your reference:

Re: SDF format

*> Isn't the renderer implementing a multi-channel SDF scheme?* *> I thought I saw multi-channel mentioned in a commit message.* *> I stumbled upon multi-channel at https://github.com/Chlumsky/msdfgen * *> where the readme seems to imply simple 8-bit

Re: SDF module now in master

*> FT_PIXEL_MODE_GRAY16 is endian-sensitive and the description implies > that we go by short int divided by 1024 in whatever endianness. Do we* * > need to say that?* I can't quite understand how the format is endian-sensitive ? If it necessary to add this to the description please do so. Anuj

Re: SDF format

Hello Alexei, *> [...] I went searching for *practical* examples on the internet and* *> found very few.* There are quite a few examples on youtube, and most of them use 8-bit buffers to represent SDF. *> This blog post>

Re: sdf: revise memory allocation debugging

1e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2020-12-26 Anuj Verma + +[sdf] Remove custom memory tracker. + + * src/sdf/ftsdf.c: Replaced `SDF_ALLOC' and `SDF_FREE' + with `FT_ALLOC' and `FT_FREE' respectively. Also, removed + the custom memory tracking functions ( `

Re: SDF module ready for integration

> That would be nice too. Can you avoid direct access altogether and use > grBlitGlyphToBitmap, which works with 256-level gray and lcd bitmaps. > So you would need to scale dimensions and bits accordingly. Yeah, while rewriting the demo program I will use the API calls instead of handling the

Re: SDF module ready for integration

> Hmmm. bV5CSType lists LCS_sRGB. I would rather switch to > BITMAPV5HEADER. Does that work for you? That should work, however, 'LCS_sRGB' is not defined in the 'wingdi.h' header file that comes with mingw ( as of the latest version ). Only 'LCS_CALIBRATED_RGB' is defined.

Re: SDF module ready for integration

> Anuj, can you change the `COPY` line in file `windows/detect.mk` > accordingly and check whether it works? Yes, it does work. ifeq ($(OS),Windows_NT) COPY := >nul cmd.exe /c copy else COPY := >nul copy endif # test NT

Re: SDF module ready for integration

> Please replace > > $(shell $(COPY) \ > $(subst /,$(SEP),submodules/dlg/include/dlg/dlg.h src/dlg/dlg)) > $(shell $(COPY) \ > $(subst /,$(SEP),submodules/dlg/include/dlg/output.h src/dlg/dlg)) > $(shell $(COPY) \ > $(subst /,$(SEP),submodules/dlg/src/dlg/dlg.c

Re: SDF module ready for integration

> OK. Anuj, do you time to work on this? My last exam is on the 25th, after that I can start rewriting the demo program. >> Right now it writes directly to the buffer assuming 24-bit (rgb888). >> So the quick fix for now is "800x600x24" on line 612. > > Thanks, it works! I have updated my

Re: SDF module ready for integration

LCS_sRGB }; + LCS_CALIBRATED_RGB }; if ( !icon ) diff --git a/ChangeLog b/ChangeLog index 73db727..fcfebf1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2020-12-23  Anuj Verma   + + [ftsdf] Fix glyph rendering issue. + + * src/ftsd

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

Hello Behdad, > Thank you Anuj. I really enjoyed observing your work this summer, even though I didn't get to contribute more review. Thank you for checking it out and for your suggestions. >> Lemma: if the closest point on curve [0,1] is to the endpoint at t=1 and the cubic equation has no

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

>> You can check it out here: >> https://gitlab.com/-/snippets/2007070 > > Thank you for this project! This is unbelievable amount of work for > just one summer. Please stay in touch and good luck in your future > adventures! Thank you Alexei! I will stay in touch. There are still many things

Re: [ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

>> I have written the final report for my project. >> >> You can check it out here: >> https://gitlab.com/-/snippets/2007070 > > Looks great, thanks! Thanks for checking it out! Anuj

[ft-devel] GSoC 2020 - Integrating Distance Field Generation in FreeType

Hello All, I have written the final report for my project. You can check it out here: https://gitlab.com/-/snippets/2007070 I'm also attaching a copy if in case the link goes down. Thanks, Anuj anuj_report.md Description: Binary data

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

>> 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

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

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

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

> 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

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

> 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

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

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

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

> 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

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

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

Re: [ft2-demos][win32] Compiler Warnings

Hello Alexei, > After I regenerated ftconfig.h with ./autogen.sh the warnings went > away for me. Do you still see it after ./autogen.sh? That doesn't seem to work on windows. The warning is because of the ` FT_INTERNAL_FUNCTION_ATTRIBUTE' macro which is defined to

Re: [ft2-demos][win32] Compiler Warnings

ORT just yet. Is this because the demos are “illegally” > built with FT2_BUILD_LIBRARY? > > Alexei > > On Jul 26, 2020, at 08:02, Anuj Verma wrote: > > > for a static lib, FT_EXPORT should be set to nothing. @Anuj Verma add > > -DFT_EXPORT to CPPFLAGS at conf

Re: [ft2-demos][win32] Compiler Warnings

> for a static lib, FT_EXPORT should be set to nothing. @Anuj Verma add > -DFT_EXPORT to CPPFLAGS at configure time Alright. It wasn't there previously tho. Anuj

Re: [ft2-demos][win32] Compiler Warnings

> it is related to FT_EXPORT in ftconfig.h I see. Thanks! > are you compiling static library of freetype ? If you compile a shared > library, you should not have this warning Yes, I am compiling a static library. And yes, they disappear when I compile a dynamic library. But I think they

[ft2-demos][win32] Compiler Warnings

Hello, There are a couple of warnings in the win32 subsystem of the freetype-2 demos. I have attached a patch to fix those. I can also see a lot of the below warning ``` src/base/ftsystem.c: In function 'FT_Stream_Open': src/base/ftsystem.c:282:3: warning: visibility attribute not supported in

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

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

Re: [freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

> OK. What about passing `__LINE__` then? Alright, I have done the relevant changes, to pass line through a function parameter I had to change `FT_DEBUG_INNER' and `FT_ASSIGNP_INNER' macros like this: ``` #define FT_DEBUG_INNER( exp ) ( _ft_debug_file = __FILE__, \

Re: [freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

> There should be zero overhead for the non-debugging case. > Having two versions would also allow to use a function internally so > that you can (a) avoid the `do {} while (0)` construction, and (b) > still use the macro within a conditional. I thought about that, but if we create a function

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

>> * `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

[freetype2] anuj-distance-field fdf4191: [sdf] Added memory tracker.

Hello Werner, How is this: https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html ? Sent from Mail for Windows 10 

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

> What exactly do you mean with 'memory debug > table'? I was thinking about the debug table that is used internally in freetype i.e. 'FT_MemTableRec'. But it is internal to 'ftdbgmem.c' I tried a lot to use some structure to track the allocations, but it requires a significant amount of changes

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

> I think having a global variable for that is a bad idea, even if it is > only active in debugging mode: If you have multiple threads you will > get nonsense information. Isn't it possible to add this variable to > one of the existing structures? Thanks for pointing that out. I can use the

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

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

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

> 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

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

> 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

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

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

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

>> 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

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

> 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

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

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

Re: [freetype2] anuj-distance-field 145c3c6 4/4: [sdf] Make squared distances toggleable.

> Nice idea, thanks! Thanks. Is it better to make it runtime toggleable by using a flag ? > Formatting nit: Please ensure that '#' is always on the first line, > so: > > #ifndef USE_SQUARED_DISTANCES > # define USE_SQUARED_DISTANCES 0 > #endif Fixed. Thanks, Anuj

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

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

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

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) > >>

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

>> 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

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

> 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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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: > >

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

> *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

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

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

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

> *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

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

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

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

> *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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

> 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

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

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

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

> *I am asking you to do some performance analysis. Specifically, would* > *you** please profile a curve and a straight segment to compare?* Sure, here is the average of 1 million iteration of computing shortest distance from a point to both types of curves and line segments: (using -O3

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

Hello Alexei, [sorry for the late very reply, my internet was down yesterday] > * How many times do you have to solve this for each glyph? * A considerable amount of time. If you want the exact number it is `width * rows * number_of_conic_curves', without any optimization. > * How many

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

Hello All, A progress update. I have ported the entire program to fixed point and it looks good to me. It's still not perfect and there are places where overflow can happen ( specifically in function `solve_cubic_equation' ), so currently I'm working on fixing those. As usual you can check it out

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

> Not a good sign of numerical stability... Yep, I have thought about scaling down all the values before computations where overflow can happen. Moreover, since the final data is normalized, It won't have any effect on the output. This is what I did from line segments and it did work without any

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

Hello All, *> Have you figured out FT_Fixed arithmetic? You still use floats in your > code. I think you should convert to FT_Fixed first. * So, I have been trying to convert my code to FT_Fixed for a few days now without any success. I did manage to use fixed point for shapes with only line

Re: GSOC - Distance Fields

*> The only remaining question is how to represent the final output data.* * > 8bit? 16bit?* I am thinking of using 16bit 2.14 to represent the final output data. Then the external application can convert the data however it wants. Anuj

Re: GSOC - Distance Fields

Hello Alexei, *> Is 1/65563 not enough accuracy for you? Do not be greedy. What would > you gain from extra accuracy in the world of discrete pixels?* 1/65563 is quite enough for SDF, my point is that in a 16.16 fixed point I will only be using 18bits ( 1 for sign, 1 for integer and 16 for

Re: GSOC - Distance Fields

Hello Behdad, Jim, *> I see that in your implementation you are converting cubics to quadratic spline. That makes a lot of sense and I support that.* Is it better to split the cubic bezier into quadratic one? why? Currently I am using Newton-Raphson's iteration to find the closest point on cubic

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

Hello Werner, *> As you like. The idea is that you can go wild within your branch, and > that you prepare another, cleaned-up branch for final GSoC submission > that contains commits in a logical order.* In that case I will start integrating the feature in FreeType. I have decided to create a

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

Hello Alexei, *> Great! Without further delay, go ahead and write a standalone program > that calculates DF for a outline glyph in whatever format you choose > or is appropriate.* I have written the program, you can find it at: https://github.com/preversewharf45/freetype2-sdf To view the

Re: resizable ft2demos

> Ok. They also say that PostQuitMessage should get me out of any modal loop. That doesn't seem to be stopping the modal loop when I tested it. And even if you break out of the modal loop the window won't resize properly. Also, the application crashes when the width/height becomes zero. So it

Re: resizable ft2demos

A callback function would be definitely much better and simpler than my solution. Anuj

Re: resizable ft2demos

I have attached the diff of my implementation. I have handled the SC_SIZE message and resize the window manually in a non blocking way. Anuj changes.diff Description: Binary data

Re: resizable ft2demos

> Is that true? Handling WM_SIZING alone was not enough. No, simply handling WM_SIZING or WM_SIZE is not enough in the current scenario. There is a separate system message SC_SIZE under the WM_SYSCOMMAND (https://docs.microsoft.com/en-us/windows/win32/menurc/wm-syscommand) which is posted when

Re: resizable ft2demos

The window enters a modal loop whenever you start resizing the window, the loop terminates when the mouse is released. more on this here: https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-entersizemove So I think the solution would be to handle the "WM_SYSCOMMAND" message and manually

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

ple ranges like > [-1.0..1.0] in general). > > - David > > Le mer. 13 mai 2020 à 16:59, Alexei Podtelezhnikov a > écrit : > >> On Wed, May 13, 2020 at 10:37 AM Anuj Verma >> wrote: >> > >> > > What do you need from FreeType to calculate

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

> What do you need from FreeType to calculate DF? > Do you see or know where to find everything you need? I will need the bitmap and/or the outline depending upon the type of font. And yes I know where to find those. They both can be accessed from FT_Face. Anuj On Wed, May 13, 2020, 7:59 PM

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

>> What exactly do you mean with 'stored as something like PNG'? Is this >> the output that FreeType returns to the calling application? Or is >> this a temporary storage within FreeType? In both cases I'm not sure >> that this is the best solution, since compression and decompression >> costs

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

g*, XML or JSON > (or, compressed version of them) would be considerable option > to store the data, during the development of the initial > draft, because it is easy for them to change the data > format, insert or remove some extra data. Also it would be > easy for ex

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

Thank you all for the comments. I too agree with Werner. I think comparing both the types seems to be a good option, So, I'm gonna do as Suzuki suggested and use floats for my initial draft and later without floats. And I'm not gonna focus on the saving part because the user can always do a

Re: GSOC - Distance Fields

Hello Alexi, Suzuki, I can't decide which format to use for storing the SDF(signed distance fields). I think using floating-point values (fixed-point in this case) for generation will be more accurate than using integer, but then saving the SDF to a file will require a conversion. So there can

GSOC - Distance Fields

Hello Alexi, Suzuki, I found a slightly better method to generate distance fields from bitmap. So, instead of the original proposed idea I want to use this instead. Is that okay? The method basically approximates edges/outlines from anti-aliased bitmaps, I have linked the paper in case you want

Re: [Freetype-devel] Re: GSOC

Hello Alexei, Thanks for the mail! > It would be a separate FT_Renderer module. > The only change in FreeType might be FT_RENDER_MODE_DF, or maybe, some interface to add that dynamically. This is what I have planned to do for vector fonts, since the FT_Renderer module converts glyph's outline to

Re: [Freetype-devel] Re: GSOC

Hello Nikhil, Thanks for the information. I will check it out and see how it goes. Anuj On Wed, May 6, 2020 at 11:47 AM Nikhil Ramakrishnan < ramakrishnan.nik...@gmail.com> wrote: > Hello Anuj, > > > > Does your computer have sufficient storage to install "Windows > Subsystem for Linux" ? > >

Re: [Freetype-devel] Re: GSOC

WSL. some virtual machine, > some > separated > machine etc would work) would be good. > > BTW, if your daily development is Visual Studio, how do you build FreeType > on > your system? > Do you use existing project file in the source tree? Or, do you use CMake? > > Regards

  1   2   >