[Fontconfig] Who is relying on the cache format on disk?

[Behdad Esfahbod]

On 14-06-25 11:49 AM, L. A. Walsh wrote:
> Other than fontconfig programs & libs, what other programs are
> relying on the exact format of the cache files on disk?
> 
> I.e. why is the internal format of the cache files, on disk, part
> of the public API?   Who (what other projects) would be
> affected if the on-disk cache format changed?
> 
> It seems like the internal format of the cache files isn't
> used outside of the font-config library.  If that's the case,
> then there is no cost to changing that format.
> 
> Who needs the cache format on disk NOT to change?

Ok, I explain this to you:

The fontconfig cache is NOT immutable.  And no one other than fontconfig
itself rely on its byte layout.  The constraints we are talking about arise
from the fact that fontconfig likes to be able to mmap the cache into the
process and return objects from it directly to the user through fontconfig
API.  This brings two challenges:

  - The cache stores offsets where the run-time generally stores pointers.  As
such, the cache layout is dependent on the pointer size of the architecture.
Now, arguably, one can change this to use a unified layout on x86 and x86-64.
 However:

  - FcValue's byte layout are exposed in the API in fontconfig.h.

Can you design a cache that isn't arch dependent?  You definitely can.  Can
you mmap that cache to memory and use it straight away without allocating
memory?  No you can't, without breaking fontconfig ABI.

Most of the other stuff you keep repeating, the things re MD5, etc, are
irrelevant to Fontconfig performance.

I already removed FC_HASH, that should give you a significant performance
boost.  I'll work on accessing loca/glyf tables directly and that should give
us another huge performance gain.  At that point, if you are willing to
implement a more efficient cache for fontconfig, come back and I'll tell you
how to do it.

behdad

-- 
behdad
http://behdad.org/