Jesper L. Nielsen wrote: > > Hi Behdad and list.. Hi, > After poking around, using gprof and other things I found a reason for > spending all the time in Fontconfig. I was calling > pango_ft2_font_map_new() for every object I wanted to draw, and > apparently this function can be reused throughout my application. > > Now I'm looking at sharing the fontconfig-cache on NFS, and as each > embedded devices share the same NFS mount, this should be simple however > I have some questions for the format. > > 1: Since the NFS mount is mounted as read/write, the first embedded > system that boots will create the cache. Does the building of cache have > a lock mechanism, or might this be a race condition? It uses directory locks. So, as long as mkdir is atomic on your NFS server and clients, you should be fine. > 2: It seems the fontcache leaves a file for every font used as it runs, > and that the filenames have a hostname appended to them? If this is > true, would it at all be possible to generate a fontconfig-cache on the > NFS server, if the embedded system doesn't share the same hostname? > Wouldn't this just generate a whole bunch of files for each embedded > device? Humm? Got sample? Which version? Fontconfig creates one cache file per font *directory*. And only appends the architecture tag to the name. > 3: Is the format of the cache files platform independent? No, but the architecture tag is part of the cache file name, so it should all work. behdad > Hope I can get some pointers now that I've regained my faith in > FontConfig :) > > All the best. > Jesper > > On Jan 9, 2009, at 11:06 AM, Jesper L. Nielsen wrote: >>> >>> Sure, building caches is slow. The first question is why is it >>> building the >>> cache on each startup. >>> >> >> Because it is on an embedded system and no place to save the caching >> database after each reboot. However I can work past that using some >> NFS trickery. >> >>>> I have been running sysprof and the majority of time spend while >>>> rendering fonts seems to be in fontconfig. >>>> >>>> I don't know how to dump Sysprof output to text, so I've attached a >>>> screendump. >>> >>> The screenshot shows nothing really. The fontconfig functions you >>> are showing >>> in the shot are taking only 3% of the total time. >>> >> >> True, I'll get some better numbers on the embedded system soon. But >> the screenshot only shows a simple test program I produced to profile >> the pango calls. So the times should be regarded as relativ, and >> kernel time used disregarded. >>>> So what I mean is that there a references to FcPattern, PangoFcFont and >>>> other things defined in the Fontconfig specific source files. So taking >>>> out just the Fontconfig part for the pangoft2.c would require some >>>> work. >>> >>> pantoft2 subclasses pangofc. So, you are pretty much talking about >>> writing a >>> new pango backend. And then, the pango shapers also depend on >>> pangofc. So >>> you have to modify those too. Really, your fighting the wrong >>> battle. Just >>> focus on getting fontconfig working for you. >>> >> I was mustering myself to write a whole new backend, but if the shaper >> also uses FontConfig, I think I'll better give FontConfig another shot. >> >> Jesper > > _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
