Re: [ft] rendering differences between 2.8 and 2.81

[Srinivasa Rao Kanaparthi]

Hi Werner,

The below is not straightforward as I cant run my program in a standalone
(no simulators). I can run only on my hardware. Please let me know is there
any other way I can do the below.

[*] If you compile the FreeType library with


      #define FT_DEBUG_LEVEL_ERROR

      #define FT_DEBUG_LEVEL_TRACE


    you can then call an application with


      FT2_DEBUG=bitmap:3 your_program


    to get md5 checksums from the generated glyph renderings.


*Coming to the actual problem,*

In the below sequence (FT_QALLOC_MULT ----> ft_mem_qrealloc ---->
*memory->malloc*), the allocated memory block is not zeroed even once.
Can this cause the difference I am observing between 2.8.0 and 2.8.1?

[image: Inline image 1]

Thanks,
Srinivas

On Thu, Oct 26, 2017 at 6:37 PM, Srinivasa Rao Kanaparthi <
address@hidden> wrote:

> Hi Werner,
>
> I will capture the details and will send soon.
>
> If my understanding is right, the fix is to prevent the memory returned
> from a ft_mem_realloc() gets zeroed twice when called with current count
> 0.
>
> But the problem introduced is when new_count is less than cur_count (*See
> the break point below*), the memory is not zeroed even once. So
> uninitialized block of memory. Please correct me if my observation is wrong.
>
> [image: Inline image 2]
>
> On a side note, our memory management is using TLSF memory allocation
> system (allocates from a pre-configured static buffer pool, on request). So
> we do replace malloc/realloc/free stdlib calls by TLSF memory interfaces.
> Thats only the difference in terms of memory management.
> http://www.gii.upv.es/tlsf/
>
> Thanks,
> Srinivas
>
> On Thu, Oct 26, 2017 at 3:02 PM, Werner LEMBERG <address@hidden> wrote:
>
>>
>> [Please always CC the list so that other interested persons can read
>> your replies.]
>>
>> > The below solves my issue
>> >
>> >           block = memory->alloc(memory, new_count * item_size);
>> >   if (!error && (new_count * item_size) > 0)
>> >   FT_MEM_ZERO(block, (new_count * item_size));
>> >
>> > The difference between the commit
>> > 0aca17cf53f099f9ea34b3797949076073b60b5d and
>> > bd28952e23bcd268a623ea5202e1cde4a92defe4 is both allocates memory,
>> > but only one initializes the allocated block to 0's.
>> >
>> > After initializing the memory block to 0's my rendering problem is
>> > resolved.
>>
>> Interesting.  The commit was introduced to exactly avoid calling
>> FT_MEM_ZERO, cf.
>>
>>   https://savannah.nongnu.org/bugs/?51816
>>
>> So please provide a small, compilable C code snippet that exhibits
>> your problem![*] As far as I know, none of the FreeType demo programs
>> show such artifacts, so it must be special to your code calling
>> FreeType...
>>
>>
>>     Werner
>>
>>
>> [*] If you compile the FreeType library with
>>
>>       #define FT_DEBUG_LEVEL_ERROR
>>       #define FT_DEBUG_LEVEL_TRACE
>>
>>     you can then call an application with
>>
>>       FT2_DEBUG=bitmap:3 your_program
>>
>>     to get md5 checksums from the generated glyph renderings.
>>
>
>