[HarfBuzz] Caching of glyphmetrics and cmap data

[Behdad Esfahbod]

On 09/24/10 00:08, Keith Stribley wrote:
> Hi Behdad,
> 
> Thanks for your quick response.
> 
> On 23/09/10 21:10, Behdad Esfahbod wrote:
>> Another, perhaps better, option is to do the caching in hb-ft.c.  I
>> think I
>> like that even more.
>>    
> 
> In this case, there will will need to be a way to store a handle to the
> cache data somehow. The hb_ft_face_create_cached, which is already
> marked as not thread-safe, stores the hb_face pointer directly in
> ft_face->generic.data. One option would be to change the generic.data to
> a pointer to a publicly defined struct holding the hb_face, glyphmetric
> and cmap caches. The cmap cache could probably remain opaque, but the
> glyphmetric cache (just an array of hb_glyph_metrics_t of length
> ft_face->num_glyphs) would potentially be modifiable by the client.

I'd rather not clutter the API with public structs and lots of API that is at
best convenience and not flexible enough for "real" use.  Let me think about
it for a bit.  Maybe we can first fix FreeType to allow more than one generic
per face, then we can fix it in hb-ft.c.

behdad


> The glyphmetric cache could either be filled in on demand, in which case
> the client would need to zero it after modifying the size of a ft_face
> or else perhaps a method should be added to pre-populate it with all
> glyph metric data, which would make it easier for the client to
> scale/swap in and out the data when the ft_face is resized.
> 
> How does that sound?
> 
> Keith
> 
>