[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. _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
