>
> >> No code. I manually called
>> >>
>> >> p /t buffer[0]
>> >> p /t buffer[1]
>> >> ...
>> >>
>> >> and did some paste & copy to produce the output (five bytes per
>> >> lines, according to the `pitch' value).
>> >
>> > When I do `p /t buffer[0]' I get `$1 = 0'.
>>
>> Yes, this is
>
> >> No code. I manually called
> >>
> >> p /t buffer[0]
> >> p /t buffer[1]
> >> ...
> >>
> >> and did some paste & copy to produce the output (five bytes per
> >> lines, according to the `pitch' value).
> >
> > When I do `p /t buffer[0]' I get `$1 = 0'.
>
> Yes, this is correct. The
>
> >> Please change the code to load a bitmap only on demand! There is
> >> absolutely no reason to load all 256 bitmaps at once.
> >
> > Yes, but it is not loading all the 256 bitmaps at once, like
> > `cmr10.600gf' has 128 glyphs, so it allocates metric values for
> > these 128 glyphs and we
>> Please change the code to load a bitmap only on demand! There is
>> absolutely no reason to load all 256 bitmaps at once.
>
> Yes, but it is not loading all the 256 bitmaps at once, like
> `cmr10.600gf' has 128 glyphs, so it allocates metric values for
> these 128 glyphs and we extract the
>
> >> BTW, why are you allocating so much memory blocks? `ftexample.c'
> >> asks for a single character, I thus expect that the GF driver loads
> >> only a single glyph...
> >
> > Oh, this may be because of 128 glyph objects + 1 GF_Glyph object.
> > Actually, the GF driver always allocates 256
>> No code. I manually called
>>
>> p /t buffer[0]
>> p /t buffer[1]
>> ...
>>
>> and did some paste & copy to produce the output (five bytes per
>> lines, according to the `pitch' value).
>
> When I do `p /t buffer[0]' I get `$1 = 0'.
Yes, this is correct. The first eight bits are zero
>
> > * If I display the 7 rows bit-wise, I get this:
> >>
> >> 00111000
> >> 0001
> >> 01101100
> >> 1010
> >>
>> BTW, why are you allocating so much memory blocks? `ftexample.c'
>> asks for a single character, I thus expect that the GF driver loads
>> only a single glyph...
>
> Oh, this may be because of 128 glyph objects + 1 GF_Glyph object.
> Actually, the GF driver always allocates 256 blocks for
> * If I display the 7 rows bit-wise, I get this:
>>
>> 00111000
>> 0001
>> 01101100
>> 1010
>> 00101000
>>
>
> > ==5604== LEAK SUMMARY:
> > ==5604==definitely lost: 80 bytes in 2 blocks
> > ==5604==indirectly lost: 45,388 bytes in 129 blocks
>
> BTW, why are you allocating so much memory blocks? `ftexample.c'
> asks for a single character, I thus expect that the GF driver loads
> only a single
>
> [commit f7a27bf38847b4531164f042088535604d3cd2ec]
>
> > I am attaching the example program I am using for checking output,
> > its the same `example1.c' program but with some slight modifications
> > to see the num_glyphs allocated.
>
> Some comments.
>
> * Your `ftexample.c' can't work
11 matches
Mail list logo
