https://bugzilla.novell.com/show_bug.cgi?id=858842
https://bugzilla.novell.com/show_bug.cgi?id=858842#c2
L. A. Walsh changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |suse@tlinx.org
Resolution|DUPLICATE |
--- Comment #2 from L. A. Walsh 2014-01-15 11:58:15 PST ---
Stefan, the bug you are reporting is not a duplicate of 853225.
Neither it is a duplicate of related bug 856476.
Besides those two bugs, there are at least 2 other bugs related to
the new font-config system, that I didn't report and are not reported
AFAIK (AsFarAsIKnow)
1) the one you mention where the entire cache is rebuilt with each font
installed: pointless. It should should be done, at MOST, once -- if user is
informed of delay and NEEDS the new font immediately after install, OR
should be scheduled for reboot asynchronously after all fonts are installed, in
background -- either immediately after all installs are done and system is
mostly quiescent (i.e. when system load <.1), OR at night during system
maintenance. (this is the bug you reported).
2) 2nd bug doubling the pain is only on 64-bit systems. If you have a 64-bit
system and have 32-bit font-rendering libraries installed -- as it runs the
*same program* in both a 64 and a 32 bit version(fc-cache & fc-cache32 I
believe -- though on 32-bit only sys, likely there is only fc-cache == 32bit).
The 32-bit version takes noticeably longer on a 64-bit system.
I may have mentioned both of the above issues, in bug #856476 -- but solving
that bug (don't regen font cache in foreground while user is waiting) doesn't
stop both fc-cache versions from running (they shouldn't), nor multiple
runs of 'fc-cache'.
Note -- this isn't a suse-only problem. I updated SW on a *windows-Cygwin*.
It tried to do a regen of the fc-cache (or fc-config?) w/each font AND it also
called fc-config, as part of gvim startup -- which took *9 minutes* to run
on a 6-core 3.4GHz, (fc-config is only single threaded -- don't see why as much
time is spent reading each file and compiling result), running in 64-bit mode
on a 4-way RAID0 using SSD's with 96G system memory.
2nd note... I can think of a 3rd bug, but low priority -- in the fontconfig
stuff in that it doesn't detect duplicate fonts and process them only once
(i.e. some broken versions of fc-config add symlinks with underscores in the
names -- unnecessary for linux (gvim, terminals et al) or Windows), and I,
personally, to save space, run a hard-linking dedup util (perl) on my font dir
-- bringing 34918 fonts down to 21467 uniq fonts -- which would save ~40% in
execution time if it was recognized. Recognizing _existing_ duplicates (hard
links) takes < 1 minute (usually alot less) on my sys. Certainly a small
amount of time compared to 5 or 10 minutes used by fc-cache[32].
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.