[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] rendering differences between 2.8 and 2.81
From: |
Werner LEMBERG |
Subject: |
Re: [ft] rendering differences between 2.8 and 2.81 |
Date: |
Thu, 26 Oct 2017 09:02:06 +0200 (CEST) |
[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.