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.
Duncan
-Original Message-
From: Werner LEMBERG [mailto:w...@gnu.org]
Sent: Sunday, August 12, 2012 3:17 AM
To: Cunningham, Duncan
Cc: freetype-devel@nongnu.org
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
as-is.
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:
http://lists.gnu.org/archive/html/freetype-devel/2012-07/msg00055.html
http://lists.gnu.org/archive/html/freetype-devel/2012-08/msg00022.html
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.
Werner
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.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
