https://bugs.winehq.org/show_bug.cgi?id=51367
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- (In reply to François Gouget from comment #0)
Created attachment 70223 [details] Command and fonts for Debian's locales
Adding fonts causes major slowdowns in dwrite:analyzer, dwrite:layout and dwrite:font when running in Wine. On my test VM I get the following run times:
Is that because of lots of global locking?
There is a global lock, yes. I don't know how much it contributes.
Or because each test adds/removes fonts forcing all the other threads to do many rescans? Are all fonts reloaded and analyzed despite most fonts not having changed?
Pretty much. There is no caching of any kind, everything listed in Fonts registry key is loaded once you create a shared font factory. Many tests intentionally don't share a factory to keep them independent.
The main reason test times depend on a number of fonts is that some tests iterate over whole collection, and test usually first of each family. I'd like to keep that because it gives a best coverage, and I was able to fix multiple problems that are hard to spot otherwise, mostly for global font properties related to table data interpretation.
Productive thing to do is to analyze which parts are particularly slow. On Windows I believe font file access is optimized by caching things at single system process level, dedicated for such font data caching. That goes back to WPF 3 I believe. It's possible we could get these times improved without such complications. For example when building default collection it currently scans a list of files for every new font, so that loop runs n*n times for n files (it's probably avoidable by collecting unique font file paths first by making enumerator a bit smarter). I don't know if that will have a noticeable impact though. Another thing is to use the global lock less, but keeping data closer to dwrite instances, rather than freetype instances.
For now, the easiest way is to limit a number of fonts so it does not timeout.