https://bugs.winehq.org/show_bug.cgi?id=51367
Bug ID: 51367 Summary: Major dwrite:analyzer, dwrite:layout and dwrite:font slowdown when adding (CJK) fonts Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
Created attachment 70223 --> https://bugs.winehq.org/attachment.cgi?id=70223 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:
Base Full set dwrite:analyzer <1s 50s dwrite:layout ~1s 46s dwrite:font ~2s 85s
On the TestBot's debiant2 VM dwrite:font actually runs in about 118 seconds with the full set of fonts; which is why it times out about 6% of the time:
https://test.winehq.org/data/patterns.html#dwrite:font
The base set of font packages is: fonts-dejavu-core fonts-freefont-ttf fonts-liberation fonts-quicksand
The problem is that the base set produces unreadable text when running in a Chinese, Japanese or Korean locale: all translated strings are replaced with a set of black squares (surprisingly ar_MA, he_IL, hi_HI are ok). That does not seem to impact the test results but it does not feel right either. At a minimum if Debian says a given set of fonts are needed for a locale we should test the said locale with that set of fonts.
So the full set of fonts was created by installing the font packages for all of Debian's locale task packages and this is what debiant2 has. See apt_wine_locales() in wt-install-dev [1]. For reference I attached the corresponding set of packages.
The run time increase is not concentrated in one specific test_xxx() function that would iterate over all the fonts. All test_xxx() functions take longer to run. Even the test_CreateFontFromLOGFONT() run time increased to ~17s (iirc). Yet it does not look like it's doing all that much.
To speed things up I modified dwrite:font to use multiple threads using the same approach as d3d10core:d3d10core. However even with 8 threads that only gained about 4 seconds out of 118s: each individual test function just took longer.
Is that because of lots of global locking? 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?
[1] https://github.com/fgouget/wt-daily/blob/master/wt-install-dev#L556