[Fontconfig] performance issue questions

[Akira TAGOH]

On Mon, Nov 28, 2016 at 2:52 PM, L. A. Walsh <fonts at tlinx.org> wrote:

>    "It happens".  My distro used to(? don't think they still do?),
> create symlinks to all the fonts that had spaces in them because some
> software they had didn't like spaces, so they created "dups" using
> underscore.  More than one program has changed case of fonts at
> one time or another -- only one that I *knew* that did this was one
> that renamed all the font-files to their font-name given internally --
> sadly it doesn't work with Unicode-filenames.


That sounds like a packaging issue. 1) why do they ship same fonts in
different packages? 2) if you means the original dirs and symlinked is
duplicated, why don't you allow scanning the unified one only then?


>    How would parallel processes working on different font-files or
> on different caches be any different than if all were updated sequentially?
> It seems the risk would be mostly the same.
>

Perhaps. but it makes things complicated.


>    Depending on the application, you could likely do the updates in
> memory using pipes or similar, though one could also use shared-memory or
> even files in /dev/shm, though those could easily overflow memory.
>

Right.


>    As for multiple processes trying to update the same cache -- happens
>

That's not true if you make sure running fc-cache when you
added/updated/deleted a font.
That is an expected workflow to use fontconfig.

since if I run gvim as a user, and it starts updating -- it can't update
> root-owned files -- and indeed, as soon as I su-to-root for something
>

You can update the system fonts without su. if you run fc-cache as an user,
all of caches for those system fonts will be created on your home directory
as needed. of course, not always. only required when the cache is outdated
or missing.

-- 
Akira TAGOH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig/attachments/20161128/b0d0a54f/attachment.html>