Keith Packard wrote:
> Around 1 o'clock on Mar 21, Patrick Lam wrote:
>
>
>>In short, I think that one would need to replace pointers with array
>>indices; to do otherwise seems to be asking for trouble. I've started a
>>patch that does this; my current patch is available at
>
>
> Yes, of course the structures need to be address independent. I was
> thinking that at the same time we'd also investigate changing the search
> algorithm and data structure to reduce the cost of searching and matching
> fonts.
>
> Right now, the cost of pattern matching scales linearaly with the number of
> fonts, when you have thousands of fonts, this isn't acceptable.
I agree. It seems that these things can be done independently, though,
and since I have little domain knowledge of fontconfig, I could probably
contribute most effectively to making things address-independent (which
is progressing slowly, but surely, in my spare time -- I hope to have a
patch ready in the near future.)
These current changes don't seem to yet require a change to the cache
format; that would come later.
BTW, Owen's suggested struct:
struct FcPattern {
int refcount;
FcPatternStorage storage; /* dynamic, static */
union {
FcPatternDynamic *dynamic;
FcPatternStatic *static;
} u;
};
still seems to be a struct, and thus requiring mallocness and a pointer.
My current patch allocates all FcPatterns in an array, which is
probably all right for FcPatterns, but not all right for FcValueLists.
Is there some safe way to use such a struct without having to malloc it?
I don't think there is.
pat
