https://bugzilla.novell.com/show_bug.cgi?id=858842 https://bugzilla.novell.com/show_bug.cgi?id=858842#c2 L. A. Walsh <suse@tlinx.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |suse@tlinx.org Resolution|DUPLICATE | --- Comment #2 from L. A. Walsh <suse@tlinx.org> 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.