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 `FT_Property_Set' to switch between the two, which I am currently using to compare performance.
Re: [Freetype-devel] Re: GSOC - Distance Fields
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 various > algorithms so that we have such a comparison. > > > The major downside of the BB and subdivision methods is that they > > require a considerable amount of memory usage (almost 3x of the size > > of bitmap) because we need to keep a track of the distances and > > signs of all the grid points. > > 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 logging message that either predicts the necessary > (approximate) amount of memory before the computation, and/or the > actual memory use after generating an SFD. 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. Vincent Torri
Re: [Freetype-devel] Re: GSOC - Distance Fields
> 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 downside of the BB and subdivision methods is that they > require a considerable amount of memory usage (almost 3x of the size > of bitmap) because we need to keep a track of the distances and > signs of all the grid points. 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 logging message that either predicts the necessary (approximate) amount of memory before the computation, and/or the actual memory use after generating an SFD. > 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) Thanks, will test soon. > For now I would like to hold the outline implementation for now and > go to the bitmap implementation. After that the module can be used > to generate SDF from bitmaps directly. It will be pretty fast and > will not require any additional memory other than the bitmap itself > at a cost of reduced accuracy. Excellent. > However there are a few issues. > > * `FT_Render_Glyph_Internal' break if the glyph format is already >a bitmap. >``` > case FT_GLYPH_FORMAT_BITMAP: /* already a bitmap, don't do anything */ > break; >``` > * `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 ? > > I don't like the idea of changing the internals of freetype so is > there any other way in which this can be done ? Don't worry about changing the internals! You know best what to do, and we can discuss later whether your solution is the right approach. Regarding the second issue I think that you probably have to create a second renderer that shares most of the code with the original one. Alexei? Werner
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 the optimization modes to the module. By far the fastest method is to subdivide the curve into a number of line segments.The coarse grid method is the slowest unless I am doing something wrong. [ Behdad, I divided the grid into 8x8 coarse grid and then to find the relevant edges of the coarse grid I am using the spread value and the half diagonal of the coarse grid. So if any edge's nearest distance to a coarse grid is greater then spread + ( coarse grid diagonal length / 2 ) I discard it. It works well and for each coarse grid I am getting around 4 edges, but it's still pretty slower than the bounding box and the subdivision method. If you need more details please let me know. ] The major downside of the BB and subdivision methods is that they require a considerable amount of memory usage (almost 3x of the size of bitmap) because we need to keep a track of the distances and signs of all the grid points. >> The image is upside down in linux maybe because in linux the y = 0 >> is at the the top which is different from windows. I'll fix it soon >> while adding bilinear filtering. 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) For now I would like to hold the outline implementation for now and go to the bitmap implementation. After that the module can be used to generate SDF from bitmaps directly. It will be pretty fast and will not require any additional memory other than the bitmap itself at a cost of reduced accuracy. However there are a few issues. * `FT_Render_Glyph_Internal' break if the glyph format is already a bitmap. ``` case FT_GLYPH_FORMAT_BITMAP: /* already a bitmap, don't do anything */ break; ``` * `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 ? I don't like the idea of changing the internals of freetype so is there any other way in which this can be done ? Thanks in advance, Anuj - KEYS -- Esc / 'q' : Quit the program. 'z': Scale up (This doesn't change point size, it just zoom the image.) 'x': Scale Down (same as above) 'Up Arrow' : Increase point size by 1. 'Down Arrow' : Decrease point size by 1. 'Page UP' : Increase point size by 25. 'Page Down': Decrease point size by 25. 'Left Arrow' : Previous Glyph 'Right Arrow' : Next Glyph 'o': Increase 'spread' by 1. 'l': Decrease 'spread' by 1. 'w', 's', : Move the glyph Up/Down. 'a', 'd' : Move the glyph Left/Right. 'f': Toggle between Nearest and Bilinear filtering. -- OPTIMIZATION MODES -- Press the relevant keys to change the optimization mode. '1': None (All grid points against all contours and all edges.) '2': Bounding Box (Use BB to improve performance by only checking the grid points in the bounding box of a edge.) '3': Subdivision (Subdivide the curve into lines then only check the grid points near the line segment) [FASTEST] '4': Coarse Grid (Divide the area into a number of coarse grids and then only check the edges relevant to the coarse grid.) -- RECONSTRUCT IMAGE FROM SDF -- 'r': Toggle between Reconstruction and Raw view. ** The keys below are only for Reconstruction mode ** - 'i': Increase Width. (Make the text bolder) 'k': Decrease Width. (Make the text thinner) 'u': Increase Edge. (Increase smoothness around the edges, similar to anti-aliasing) 'j': Decrease Edge. (Decrease smoothness around the edges, makes the text sharper) - END --
Re: Logging Library-GSOC
Hi again, I accidentally sent the previous mail Continuing to the previous mail... Also in the requirements, you told me to provide an option in MakeFile `make dist` to build the external library. But dlg uses meson build system and I don't have any idea how to combine meson build system with MakeFile, therefore could you provide me some references from where I can read about doing this... Thanks, Priyesh On Tue, Jul 14, 2020 at 4:37 PM Priyesh kumar wrote: > Hi, > I have added an option in `FT2_DEBUG` environment variable to > enable/disable the > printing of FT_COMPONENT and Timestamp with a log message. > The discussion related to dlg's features is still going, therefore in the > meantime I was > thinking of extending the support on Windows. > After looking: builds/windows/vc2010 , builds/windows/visualc > and builds/windows/visulace > I can see that they all depend on builds/windows/ftdebug.c, therefore I > wanted to ask that > Do I have to change only this file or there are some other files that I > have to take care of? > > Also in the requirements, you told me to provide an option in MakeFile > `make dist > > On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar > wrote: > >> Hi armin, >> >> *> This would print wrong-ish timestamps that couldn't really be used for >> profiling (I mean, it could; you just have to know which timestamp belongs >> to which message). I would suggest to * >> *> rather store a flag after reading `\n` and attach the timestamp to the >> following message.* >> >> I am also following this approach for printing timestamp and FT_COMPONENT. >> Actually dlg uses a flag `dlg_features` in which different features like >> `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for >> FT_COMPONENTS) are summed up using binary *OR *operator. >> For the first log message, these flags are kept ON so that timestamp and >> FT_COMPONENT values are printed, and for the next coming log messages the >> following logic is used: >> If the current log message contains a `\n` in it then the flags will be >> toggled ON for the next coming log message assuming that it is end of a log >> message, >> and if the current log message doesn't contain `\n` then these flags are >> toggled OFF for the next coming log message assuming that it is in >> continuation of current log message. >> >> *> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather >> fast, esp. given that this is followed by an IO operation. To be tested >> though :)* >> OK >> >> *> Writing this lead me to look for multi-linebreak traces (e.g. >> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire >> statement or one timestamp per line?* >> >> With the above logic for these types of logs, there will be one timestamp >> per line... >> >> Thanks, >> Priyesh >> >> On Sun, Jul 12, 2020 at 2:02 PM wrote: >> >>> > Since debugging isn't time critical it might be necessary to add an >>> additional >>> > step that scans tracing messages for newline characters, then >>> massaging the >>> > output by inserting the time stamp. In other words, all occurrences of >>> > >>> > `\n` >>> > >>> > should be replaced with >>> > >>> > `\n[time stamp] ` >>> > >>> > or something similar. >>> >>> This would print wrong-ish timestamps that couldn't really be used for >>> profiling (I mean, it could; you just have to know which timestamp belongs >>> to which message). I would suggest to rather store a flag after reading >>> `\n` and attach the timestamp to the following message. Also, I would >>> believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that >>> this is followed by an IO operation. To be tested though :) >>> >>> Writing this lead me to look for multi-linebreak traces (e.g. >>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire >>> statement or one timestamp per line? >>> >>> Armin >>> >>>
Re: Logging Library-GSOC
Hi, I have added an option in `FT2_DEBUG` environment variable to enable/disable the printing of FT_COMPONENT and Timestamp with a log message. The discussion related to dlg's features is still going, therefore in the meantime I was thinking of extending the support on Windows. After looking: builds/windows/vc2010 , builds/windows/visualc and builds/windows/visulace I can see that they all depend on builds/windows/ftdebug.c, therefore I wanted to ask that Do I have to change only this file or there are some other files that I have to take care of? Also in the requirements, you told me to provide an option in MakeFile `make dist On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar wrote: > Hi armin, > > *> This would print wrong-ish timestamps that couldn't really be used for > profiling (I mean, it could; you just have to know which timestamp belongs > to which message). I would suggest to * > *> rather store a flag after reading `\n` and attach the timestamp to the > following message.* > > I am also following this approach for printing timestamp and FT_COMPONENT. > Actually dlg uses a flag `dlg_features` in which different features like > `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for > FT_COMPONENTS) are summed up using binary *OR *operator. > For the first log message, these flags are kept ON so that timestamp and > FT_COMPONENT values are printed, and for the next coming log messages the > following logic is used: > If the current log message contains a `\n` in it then the flags will be > toggled ON for the next coming log message assuming that it is end of a log > message, > and if the current log message doesn't contain `\n` then these flags are > toggled OFF for the next coming log message assuming that it is in > continuation of current log message. > > *> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather > fast, esp. given that this is followed by an IO operation. To be tested > though :)* > OK > > *> Writing this lead me to look for multi-linebreak traces (e.g. > src/pcf/pfcread.c:504) -- should that have one timestamp for the entire > statement or one timestamp per line?* > > With the above logic for these types of logs, there will be one timestamp > per line... > > Thanks, > Priyesh > > On Sun, Jul 12, 2020 at 2:02 PM wrote: > >> > Since debugging isn't time critical it might be necessary to add an >> additional >> > step that scans tracing messages for newline characters, then massaging >> the >> > output by inserting the time stamp. In other words, all occurrences of >> > >> > `\n` >> > >> > should be replaced with >> > >> > `\n[time stamp] ` >> > >> > or something similar. >> >> This would print wrong-ish timestamps that couldn't really be used for >> profiling (I mean, it could; you just have to know which timestamp belongs >> to which message). I would suggest to rather store a flag after reading >> `\n` and attach the timestamp to the following message. Also, I would >> believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that >> this is followed by an IO operation. To be tested though :) >> >> Writing this lead me to look for multi-linebreak traces (e.g. >> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire >> statement or one timestamp per line? >> >> Armin >> >>
