On Saturday 26 March 2005 12:49, Owen Taylor wrote:
> On Sat, 2005-03-26 at 10:10 +0100, Lars Knoll wrote:
> > On Friday 25 March 2005 22:25, Owen Taylor wrote:
> > > On Fri, 2005-03-25 at 01:53 -0500, Patrick Lam wrote:
> > > > 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.
> > >
> > > The point of my suggestion is that we need a single *public* structure
> > > for:
> > >
> > > - Patterns retrieved from the database of fonts on disk
> > > - Patterns created on the fly through the FcPattern API
> > >
> > > But that public structure can be small, lightweight, and created on
> > > the fly.
> >
> > Do you really? FcPattern is a completely opaque type. For patterns on the
> > disk, you can just return a pointer to them. All that should be needed is
> > one bitflag in the pattern structure itself marking it a begin readonly,
> > and using the same data structure for dynamic patterns.
> >
> > This requires using the same endianness and packing for dynamic and
> > static patterns and thus makes building up dynamic pattern a little more
> > complex, but I don't think the overhead would be noticable (and the code
> > is needed for the cache building anyway). The advantage would the that
> > retrieving of properties from the pattern could use the same code.
>
> My thought that it would be hard to create a structure that both worked
> on disk and was suitable for efficient implementation operations like
> FcPatternAdd/FcPatternDel. The fundamental problem I see is that
> FcPatternAdd requires allocating more storage, but you can't call
> realloc on the FcPattern pointer.
Hmmm... true. The need to allocate more space spoils the whole possibility of
static and dynamic patterns using exactly the same structure. I still think
that you could probably avoid the overhead of allocating anything for static
patterns with a pattern as below:
struct FcPattern {
int Type; // Dynamic or Static
};
struct FcPatternStatic {
FcPattern p;
FcPatternData data;
};
struct FcPatternDynamic {
FcPattern p;
int refcount;
FcPatternData *data;
};
That way you have almost the same data structure for both types. The only
difference would be the way to get a pointer to the pattern data.
> I could be missing some tricky way to set things up, however.
>
> Changing things so that a static FcPattern was only one memory block
> would be easier, though if you don't reference count static patterns,
> you may have trouble with font database changes,
Won't font database changes require mmaping the new cache file? In that case
you probably need a global refcount for all patterns in the mmaped file, so
you know when nothing references the old cache file anymore.
Cheers,
Lars
