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 memory debug table if > it contains the total size allocated? What exactly do you mean with 'memory debug table'? > I'll see if I can add it in some existing structure. OK, thanks. Werner
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 memory debug table if it contains the total size allocated ? I'll see if I can add it in some existing structure. Meanwhile I have reverted this commit. Anuj
Re: [Freetype-devel] Re: GSOC - Distance Fields
>> 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 such as `spread' there is no other way to dynamically set > it. You definitely should use `FT_Property_Set`. However, as done in other modules, we declare (some of) the properties as 'experimental' in the documentation so that we can change or remove them if necessary. Werner
Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.
> * src/sdf/ftsdf.c (*): Replaced `FT_QNEW' and `FT_ALLOC_MULT' to > custom macros in order to track memory allocations throughout > the process of generating SDF. It basically add the memory > being allocated to a static global variable and at the end > outputs it at the end. 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? Werner
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 separately. However to keep it consistent with the rest of the renderers we might need to add it. > 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 such as `spread' there is no other way to dynamically set it. Anuj
Re: [Freetype-devel] Re: GSOC - Distance Fields
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 whether we need FT_LOAD_TARGET_SDF for FT_Load_Glyph? Indeed, the bitmap-to-sdf renderer should be separate as it hardly shares anything. 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. Alexei
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 logging message that either predicts the necessary > (approximate) amount of memory before the computation, and/or the > actual memory use after generating an SFD. Alright, I will add a log message about the exact memory used after generating the SDF. Is there any profiling tool built into FreeType? If there is the exact time can be logged as well. > 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? Okay, I will probably only need to remove this case statement. ``` case FT_GLYPH_FORMAT_BITMAP: /* already a bitmap, don't do anything */ break; ``` And yeah I like the idea of creating a seperate renderer, since it won't be used much. The only cases I can think of where SDF from bitmap will be generated is either for bitmap fonts or for glyphs with overlapping contours( until I add something to remove the overlapps ). So, if it is a separate module it can easily be disabled. >> 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 showing the list of keys. > > * Easy navigation to get to large glyph indices easily. I will later create the demo from scratch, so will add these. > * It probably makes sense to not allow 'Width' values in > reconstruction mode to be larger than '(Spread - 1)' or something > similar, emitting a warning if this threshold is reached. Otherwise > you get white boxes without a warning. Yeah, I forgot about that. The `Width' shouldn't exceed `(Spread - 1)' Thanks for pointing that out, I will add this while creating the new demo. Thanks, Anuj
Re: [Freetype-devel] Re: GSOC - Distance Fields
> 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 showing the list of keys. * Easy navigation to get to large glyph indices easily. * It probably makes sense to not allow 'Width' values in reconstruction mode to be larger than '(Spread - 1)' or something similar, emitting a warning if this threshold is reached. Otherwise you get white boxes without a warning. Werner
