<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Make fontconfig scanning faster" href="https://bugs.freedesktop.org/show_bug.cgi?id=64766#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Make fontconfig scanning faster" href="https://bugs.freedesktop.org/show_bug.cgi?id=64766">bug 64766</a> from <a class="email" href="mailto:nfxjfg@gmail.com" title="nfxjfg@gmail.com">nfxjfg@gmail.com</a> <pre>(In reply to <a href="show_bug.cgi?id=64766#c6">comment #6</a>) > (In reply to <a href="show_bug.cgi?id=64766#c5">comment #5</a>) > > Somehow freetype seems to spend rather a lot of effort on that. I don't know > > how this stuff works, but to my naive eyes is looks like there's further > > optimization possible, though possibly that would require changes in > > freetype instead of fontconfig. > > I may take a look. We load all glyphs just to make sure the font actually > has it, as opposed to having bogus or empty glyphs. Maybe that level of > paranoia is not quite needed these days... Can't this be done when attempting to use the glyph? > > For example, the granularity of the cache could be changed and create a new > > cache for every 20 files or so. > > Each cache file would mean one more mmap() in every fontconfig-using client. > That's already bad enough... Sure, you'll perhaps need more mmap calls. But that's much better than blocking an application on font scanning. You could also create a light weight central index (which can be easily reconstructed when a "sub"-cache changes), and map the cache file only when it's needed. Well, I don't know what exactly the font cache stores, but maybe this can serve as inspiration. > > Or it could be made such that the old cache > > is reused for files that have not changed. No doubt, these changes would be > > intrusive to the cache code, but given the problems with font scanning > > times, I think it would be worth it. > > > > Now that you have added a hash for each font, maybe it would be possible to > > cache the results for memory fonts as well? Hashing actually makes loading a > > font even slower, but since you're doing it anyway, maybe it could be used > > for that purpose as well. > > Yeah, maybe we can have a cache of individual fonts based on hashes. Then > we can rebuild directory caches based on those individual fonts much faster. > > For memory fonts, is it really a big deal? Why do people query those anyway? Yes, it's a big deal. There are many use cases for memory fonts, such as embedding fonts in Matroska (mkv) files, web-fonts, fonts embedded in documents, special application-specific fonts. By the way, I think adding font hashes just made font scanning slower for an obscure feature that probably will have only one user at best...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>