- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Feb 2019 11:28:30 +0000
- To: public-css-archive@w3.org
Unfortunately I could not attend the meeting, but I do not find the string comparison a problematic performance aspect of font matching either. I agree with @litherum that font family matching is a hot code path but usually performance issues arise due to the fact that a potentially large number of fonts need to be indexed / their metadata needs to be accessed or cache to perform matching. The performance issues are not in performing string comparisons once the metadata is available. For Chrome, we have multiple backends: On Windows we do what: https://docs.microsoft.com/en-us/windows/desktop/api/dwrite/nf-dwrite-idwritefontcollection-findfamilyname does, which seems to be a unicode case fold, not an ASCII only one. On Linux and ChromeOS we do what FcPatternAddString for family + FcFontSort do. I haven't looked into the implementation of this to see what matching algorithm is used there. (@behdad - do you know what matching algorithm FC uses for family name comparisons?) On Android which case insensitively match against alias names in the android fonts.xml configuration which are only specified there in Latin. On Mac we use NSString caseInsensitiveCompare which does not seem to be restricted to ASCII according to https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Strings/Articles/SearchingStrings.html#//apple_ref/doc/uid/20000149 (Unrelated: For the the upcoming fixes for src: local() matching in android we use ICU's FoldCase). We have little control over the system APIs string matching behavior other than implementing our own full font indexer and lifting all metadata out of the system caches and performing our own matching operations, which I don't think we will do anytime soon. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3675#issuecomment-468238875 using your GitHub account
Received on Thursday, 28 February 2019 11:28:31 UTC