>> * `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 of the code with the original one.
So, I started adding the new renderer module for the bitmap to sdf conversion. Is that okay? i.e. adding a new module named `sdfb'. Or should I just create another renderer in the same module and add it to the `module.mk' ? something like this: ``` FTMODULE_H_COMMANDS += SDF_RENDERER FTMODULE_H_COMMANDS += SDF_BITMAP_RENDERER define SDF_RENDERER $(OPEN_DRIVER) FT_Renderer_Class, ft_sdf_renderer_class $(CLOSE_DRIVER) $(ECHO_DRIVER)sdf $(ECHO_DRIVER_DESC)signed distance field renderer$(ECHO_DRIVER_DONE) endef define SDF_BITMAP_RENDERER $(OPEN_DRIVER) FT_Renderer_Class, ft_sdf_bitmap_renderer_class $(CLOSE_DRIVER) $(ECHO_DRIVER)sdfb $(ECHO_DRIVER_DESC)bitmap to signed distance field converter$(ECHO_DRIVER_DONE) endef #EOF ``` 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. Thanks, Anuj On Wed, Jul 15, 2020 at 10:43 AM Werner LEMBERG <w...@gnu.org> 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. > > > 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 >
