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

[Anuj Verma]

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