[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] [PATCH] Stroked Glyph Caching

From: Cunningham, Duncan
Subject: Re: [ft-devel] [PATCH] Stroked Glyph Caching
Date: Mon, 13 Aug 2012 14:25:52 +0000

I think the use of the properties for the caching amounts is a good solution.  
The only thing I would point out is if the stroker cache uses this new 
properties API for configuration, we should also make sure the cache maximums 
for faces and sizes can also be configured with this API.  I think it is 
important to have a consist API so the user doesn't get confused.


-----Original Message-----
From: Werner LEMBERG [mailto:address@hidden
Sent: Sunday, August 12, 2012 3:17 AM
To: Cunningham, Duncan
Cc: address@hidden
Subject: Re: [ft-devel] [PATCH] Stroked Glyph Caching

> I have added support to cache stroked glyphs.  This introduces
> caching for stroked glyphs for both a sbitmap, and a regular image
> glyph.  Also, support has been added to the FTC_Manager to cache
> FT_Stroker objects.

I've just had a closer look, and it looks very good!

> Modified API:
> * FTC_Manager_New() - now takes an additional argument for the
> *                     number of FT_Stroker objects to cache.

This is a problem, and I ask others to chime in for discussion.  While
the FreeType cache code is tagged as beta, I believe that many
applications already use it.  Additionally, its interface hasn't
changed for a long time, so it is probably better to stay with it

In general, I don't like the approach of FTC_Manager_New to specify
maximum values for various objects.  As your patch shows, it makes it
virtually impossible to extend the cache functionality without
breaking the API.

Instead, I suggest to use properties, cf. this thread:

What do you think?  I'll soon start with coding the infrastructure.

> One thing I would note about the patch is the hash of a
> FTC_StrokerTypeRec just adds the data together.  I don't think this
> is the best hash method, but hopefully you guys have some better
> ideas.

Regarding myself, I don't have a better idea :-) Maybe there are
people on this list who have more experience with that.



This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient. If you are not the intended recipient, please be 
aware that any disclosure, copying, distribution or use of this e-mail or any 
attachment is prohibited. If you have received this e-mail in error, please 
contact the sender and delete all copies.

Thank you for your cooperation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]