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