| Summary: | Keep index by family name | ||
|---|---|---|---|
| Product: | fontconfig | Reporter: | Owen Taylor <otaylor> |
| Component: | library | Assignee: | fontconfig-bugs |
| Status: | RESOLVED WONTFIX | QA Contact: | Behdad Esfahbod <freedesktop> |
| Severity: | normal | ||
| Priority: | high | CC: | akira, billy.biggs, bugs.freedesktop, dpollock, freedesktop, mlists |
| Version: | 2_1 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
http://freedesktop.org/pipermail/fontconfig/2004-August/000992.html has a patch from Brian Ryner. I think this ties rather tightly into my hoped-for redesign of the cache files into something suitable for shared mmaping. Let's work on this for fontconfig 2.4, and also restructure the matching algorithm to better support CSS2. Couldn't find the patch. FcFontSetMatch is, alas, still O(n), but the constant should be much smaller now... Keith, now with mmap there, do you have any idea how to fasten things up? Mapped cache files don't really affect this issue. What is needed is a new pattern matching design which performs some CSS-ish match algorithm instead of the current global scoring. I know most fontconfig users now cache match results; would it still be useful to come up with a more efficient basic font matching system? Would the abilty to do more CSS-compatible matching make this worthwhile even if performance is no longer a significant concern? Anything like that would be fontconfig3, so we can close this right now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Currently, the way to walk over all fonts in the system with Pango is for family in fontmap.list_families(): for face in family.list_faces(): description = face.describe() What Pango stores for a family is the family name, and to get to the list of faces for that family, it calls FcFontList() What Pango stores for the face is the family and style, and to get to the details of the face, it calls FcFontMatch(). Since FcFontList() and FcFontMatch() are O(n_fonts_on_system), the above algorithm is O(n_fonts_on_system^3) ! Now, I can optimize this somewhat in Pango by storing a reference to the full pattern with the face object, but I dont' think it's unreasonable to expect that a call to FcFontList or FcFontMatch that includes a family name should be O(1) not O(n_fonts_on_system). The memory usage for a hash table from family=>fonts with that family should be minimal compared to the total memory usage for fontconfig.