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

[Werner LEMBERG]

> How is this:
> https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html
> ?

Nice!  However, I think it's better to have two versions of
`SFD_ALLOC` and `SFD_FREE` depending on whether debugging is enabled
or not.  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 imagine something like
the following sketch.

  #ifdef DEBUGGING

typedef struct SDF_MemoryUser_ { ... } ...

FT_Pointer
sdf_alloc(...)
{
  ...
}

  #define SDF_ALLOC ...

  #else

  #define SDF_ALLOC FT_QALLOC

  #endif


Werner

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

[Alexei Podtelezhnikov]

Hi Anuj

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

Same module with two renderers as you described makes sense to me too.

Alexei

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

Re: Logging Library-GSOC

[Priyesh kumar]

Hello,
I have tried the query performance counter/frequency method for example
program:
(https://www.freetype.org/freetype2/docs/tutorial/example1.c)
on Windows with arial.ttf and FT2_DEBUG=any:7 on
string:"qwertyuiopasdfghjklzxcvbnm"
which produced 24260 logs.
I have executed the test program multiple times and below are the average
time for each case in seconds:
FT_LOGGING:8 sec ( writes logs to file freetype.log)
FT_DEBUG_LEVEL_TRACE: 40 sec (writes logs to stderr)
NO_DEBUGGING:7  sec
I have also prepared a test program for this @ here
 ,
so that if anyone wants to test they can also try and test the results...
The Visual Studios solution contains three different configurations for the
x64 platform:
FT_LOGGING: linked with FreeType library built with FT_LOGGING macro
enabled.
FT_DEBUG_LEVEL_TRACE: linked with FreeType library built with
FT_DEBUG_LEVEL_TRACE macro enabled.
NO_DEBUGGING: linked with release built of FreeType library

Please look into this and provide feedback...

Thanks,
Priyesh




On Thu, Jul 16, 2020 at 11:24 AM Priyesh kumar 
wrote:

> Hi Vincent,
> Thanks for the suggestion it seems very helpful, I will try it and let you
> know in case of any query.
>
> Thanks,
> Priyesh
>
> On Thu, Jul 16, 2020 at 4:14 PM Vincent Torri 
> wrote:
>
>> On Thu, Jul 16, 2020 at 9:51 AM Werner LEMBERG  wrote:
>> >
>> >
>> > >> *Have you set `FT2_DEBUG=any:7` in the environment?*
>> > >
>> > > Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
>> > > OpenSans-Bold.ttf font.
>> >
>> > OK.
>> >
>> > > Also, I wanted to ask is this the right approach for profiling?
>> >
>> > I'm not an expert, sorry.  However, you might also try `valgrind
>> > --tool=cachegrind` (on GNU/Linux), which gives you detailed
>> > information on used CPU cycles including instruction and data caches.
>>
>> also
>> valgrind --tool=callgrind + kcachegrind
>> and
>> oprofile could be useful
>>
>> Vincen Torri
>>
>