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

[Anuj Verma]

Hello Werner, How is this: https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html ? Sent from Mail for Windows 10 

Re: [freetype2] anuj-distance-field d97e060: [sdf] Added total memory allocation log.

[Anuj Verma]

> What exactly do you mean with 'memory debug > table'?

I was thinking about the debug table that is used
internally in freetype i.e. 'FT_MemTableRec'. But it is internal to
'ftdbgmem.c'

I tried a lot to use some structure to track the
allocations, but it requires a significant amount
of changes to the existing code, so I'll just
approximate the memory usage and output that.

Thanks,
Anuj

On Thu, Jul 16, 2020, 11:23 AM Werner LEMBERG  wrote:

>
> >> 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: [Freetype-devel] Re: GSOC - Distance Fields

[Alexei Podtelezhnikov]

> On Jul 16, 2020, at 00:42, Werner LEMBERG  wrote:
> 
> 
>>> 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.

Yes. For example, the spread probably defines the range of reliable 
interpolations. So this option is solidly user-relevant. The algorithm, on the 
other hand is a developer option to experiment with. A user should not expect 
this option to be perpetually available as new algorithms might be offered and 
the old ones dropped. Perhaps, a development option is a better name.

Alexei

Re: Logging Library-GSOC

[Priyesh kumar]

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
>

Re: Logging Library-GSOC

[Vincent Torri]

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

Re: Logging Library-GSOC

[Vincent Torri]

On Thu, Jul 16, 2020 at 8:30 AM Priyesh kumar  wrote:
>
> Hi,
> I was trying profiling on the example program given @ here.
> I have used the profiling tool inbuilt in Visual Studios but was unable to
> extract useful information from it, therefore I have tried a solution provided
> on Stack Overflow @ here . It basically uses `clock()` function to calculate 
> the
> running time of the program.

you can use query performance counter/frequency on Windows. I find
them a bit more accurate than anything else :

static LARGE_INTEGER freq;
static LARGE_INTEGER count1;
static LARGE_INTEGER count2;

you call once, at the beginning :
QueryPerformanceFrequency();

before the code you want to profile :

QueryPerformanceCounter();

at the end :

QueryPerformanceCounter();

number of seconds (as a double ):
double t = (double)((count2.QuadPart - count1.QuadPart) / freq.QuadPart);

regards

Vincent Torri




> So, basically I have used two variables of type time_t one at the start and 
> one
> at the end of the program marking the clock time at those steps and in the end
> the program prints the time taken by the program in seconds.
> For averaging out the result I have used a  for loop running the example code 
> 10
> times every time the code is is executed and at the end of each iteration it 
> writes the difference
> between the start time and end time to a file in seconds.
> I have attached the file in which it writes the results.
> I have tested the above solution on Ubuntu 20.04 LTS and got the following 
> results:
> No Debugging mode (avg time: 0.0164531 sec)
> Debugging using FT_DEBUG_LEVEL_TRACE mode (avg time: 0.0988122 sec)
> Debugging using FT_LOGGING mode (avg time: 0.0512144)
>
> Please look into this and provide feedback...
>
> Thanks,
> Priyesh
>
>
>
> On Tue, Jul 14, 2020 at 4:43 PM Priyesh kumar  wrote:
>>
>> 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

Re: Logging Library-GSOC

[Werner LEMBERG]

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


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

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



*> You should also use a> well-hinted TrueType font like 'Arial' to get a
large bunch of> instruction debugging.*

Thanks, I will use this font.
Also, I wanted to ask is this the right approach for profiling?

Thanks,
Priyesh

On Thu, Jul 16, 2020 at 12:18 PM Werner LEMBERG  wrote:

>
> > I was trying profiling on the example program given @ here
> > .  I
> > have used the profiling tool inbuilt in Visual Studios but was
> > unable to extract useful information from it, therefore I have tried
> > a solution provided on Stack Overflow @ here
> >  >
> > .  It basically uses `clock()` function to calculate the running
> > time of the program.
>
> OK.
>
> > So, basically I have used two variables of type *time_t *one at the
> > start and one at the end of the program marking the clock time at
> > those steps and in the end the program prints the time taken by the
> > program in seconds.  For averaging out the result I have used a *for
> > *loop running the example code 10 times every time the code is is
> > executed and at the end of each iteration it writes the difference
> > between the start time and end time to a file in seconds.
> >
> > I have attached the file in which it writes the results.
>
> Well, those numbers vary far too much to have any significance.  I can
> only see that an execution without debugging is faster.  Have you set
> `FT2_DEBUG=any:7` in the environment?  This will make FreeType very
> chatty and thus should give better numbers.  You should also use a
> well-hinted TrueType font like 'Arial' to get a large bunch of
> instruction debugging.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> I was trying profiling on the example program given @ here
> .  I
> have used the profiling tool inbuilt in Visual Studios but was
> unable to extract useful information from it, therefore I have tried
> a solution provided on Stack Overflow @ here
> 
> .  It basically uses `clock()` function to calculate the running
> time of the program.

OK.

> So, basically I have used two variables of type *time_t *one at the
> start and one at the end of the program marking the clock time at
> those steps and in the end the program prints the time taken by the
> program in seconds.  For averaging out the result I have used a *for
> *loop running the example code 10 times every time the code is is
> executed and at the end of each iteration it writes the difference
> between the start time and end time to a file in seconds.
>
> I have attached the file in which it writes the results.

Well, those numbers vary far too much to have any significance.  I can
only see that an execution without debugging is faster.  Have you set
`FT2_DEBUG=any:7` in the environment?  This will make FreeType very
chatty and thus should give better numbers.  You should also use a
well-hinted TrueType font like 'Arial' to get a large bunch of
instruction debugging.


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have added an option in `FT2_DEBUG` environment variable to
> enable/disable the printing of FT_COMPONENT and Timestamp with a log
> message.

Looks good, thanks.

> After looking at builds/windows/vc2010, builds/windows/visualc and
> builds/windows/visualce 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?

AFAIK, it's only this file.  Alexei?

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

I suggest the following.

(1) Use a different directory (for example
`/submodules/dlg`) for checking out the `dlg`
submodule.  This subdirectory won't get distributed with the
FreeType tarball.

(2) Create subdirectory `src/dlg`, which only holds a `rules.mk` file.

(3) Change the `autogen.sh` script to copy the necessary files from
`/submodules/dlg` to `src/dlg`.

(4) Modify the `setup` target in `builds/toplevel.mk` to do the same
as (3).  This is necessary for builds that don't use the
`configure` script (for example `make devel; make`).  Be careful
to use the right variables like `OBJ_DIR` so that it possible to
allow builds that use a read-only source directory.


Werne

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,
I was trying profiling on the example program given @ here
.
I have used the profiling tool inbuilt in Visual Studios but was unable to
extract useful information from it, therefore I have tried a solution
provided
on Stack Overflow @ here
 .
It basically uses `clock()` function to calculate the
running time of the program.
So, basically I have used two variables of type *time_t *one at the start
and one
at the end of the program marking the clock time at those steps and in the
end
the program prints the time taken by the program in seconds.
For averaging out the result I have used a  *for *loop running the example
code 10
times every time the code is is executed and at the end of each iteration
it writes the difference
between the start time and end time to a file in seconds.
I have attached the file in which it writes the results.
I have tested the above solution on Ubuntu 20.04 LTS and got the following
results:
No Debugging mode (avg time: 0.0164531 sec)
Debugging using FT_DEBUG_LEVEL_TRACE mode (avg time: 0.0988122 sec)
Debugging using FT_LOGGING mode (avg time: 0.0512144)

Please look into this and provide feedback...

Thanks,
Priyesh



On Tue, Jul 14, 2020 at 4:43 PM Priyesh kumar 
wrote:

> 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