To work around a warning with GCC10 on Win32
warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=]
Before this change building with ThreadSanitizer and running
test/test-pthread generated a large number of threading issues. These
mostly stemmed from fc_atomic_ptr_get not doing an atomic load and using
"acquire load" instead of "load acquire". After making these changes it
was still necessary to use fc_atomic_ptr_get where it was needed.
This also documents the current memory barrier requirements for the
atomic primitives.
Some systems build FreeType using CMake rather than autotools (such as Visual
Studio), which will give us CMake config files rather than pkg-config files, so
if we can't find FreeType using pkg-config, try again using CMake.
Please note that according to FreeType's docs/VERSIONS.TXT, the version we want
when checking with CMake is 2.8.1 or later.
OpenType spec says that the Regular descriptor would generally be
omitted from fullname. but some fonts doesn't follow on it.
So decided to construct a fullname from family and style instead of
relying on the meta data in a font.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/208
We were using the family names from the pattern without
copying, and this was leading to a valgrind warning:
==53167== Invalid read of size 1
==53167== at 0x58B0238: FcStrCaseWalkerNextNonBlank (fcstr.c:198)
==53167== by 0x58B0238: FcStrCaseWalkerNextNonBlank (fcstr.c:186)
==53167== by 0x58B02C7: FcStrCmpIgnoreBlanksAndCase (fcstr.c:281)
==53167== by 0x58A4D44: FcHashTableFind (fchash.c:109)
==53167== by 0x5895E76: FamilyTableAdd (fccfg.c:1634)
==53167== by 0x589646A: FcConfigAdd.isra.0 (fccfg.c:1823)
==53167== by 0x58988CF: IA__FcConfigSubstituteWithPat.part.0 (fccfg.c:2228)
==53167== by 0x55F4F1A: pango_cairo_fc_font_map_fontset_key_substitute (pangocairo-fcfontmap.c:106)
==53167== by 0x5B88AF6: pango_fc_default_substitute (pangofc-fontmap.c:1795)
==53167== by 0x5B88D15: pango_fc_font_map_get_patterns (pangofc-fontmap.c:1850)
==53167== by 0x5B88FC7: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1952)
==53167== by 0x5623627: pango_font_map_load_fontset (pango-fontmap.c:161)
==53167== by 0x5621743: pango_context_get_metrics (pango-context.c:1782)
==53167== Address 0x150d3450 is 0 bytes inside a block of size 10 free'd
==53167== at 0x483B9F5: free (vg_replace_malloc.c:538)
==53167== by 0x58ABE70: FcValueListDestroy (fcpat.c:147)
==53167== by 0x5898A08: IA__FcConfigSubstituteWithPat.part.0 (fccfg.c:2203)
==53167== by 0x55F4F1A: pango_cairo_fc_font_map_fontset_key_substitute (pangocairo-fcfontmap.c:106)
==53167== by 0x5B88AF6: pango_fc_default_substitute (pangofc-fontmap.c:1795)
==53167== by 0x5B88D15: pango_fc_font_map_get_patterns (pangofc-fontmap.c:1850)
==53167== by 0x5B88FC7: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1952)
==53167== by 0x5623627: pango_font_map_load_fontset (pango-fontmap.c:161)
==53167== by 0x5621743: pango_context_get_metrics (pango-context.c:1782)
Use copies of the strings as keys in the hash table to avoid this.
Recently some python scripts has been added to the build toolchain for meson build support. but we don't want to maintain multiple files for one purpose. since autotools build support will be guradually discontinued, integrating those scripts into autotools would be better.
Make FcConfigPromote use a switch instead of
an if-else cascade, and avoid calling it when
we can.
Note that we need to add a case for integers
in FcConfigCompareValue, since we are no longer
promoting integers to doubles unconditionally.
When we don't need to differentiate between weak and strong,
we can exit the loop in FcCompareValueList once we found a
best match.
This change helps reducing the amount of list walking we do
for fonthashint, where careless config files end up creating
lists with ~100 booleans :( We don't want to walk all those
to the end, over and over again.
We are already special-casing family, and the only other case
where weak != strong, PostScript names, doesn't have long lists
of values, so the limitation to weak == strong doesn't matter
much in practice.
When checking whether a test matches a pattern,
we cut the loop short for FcQualAll when we see
the first non-matching value, but for FcQualAny
we were always walking the full list. This patch
cuts the loop short for FcQualAny when we see the
first matching value.
With the way typical font configurations look, matching the lists
of families is the bottleneck for both FcFontMatch and FcFontSort.
After installing the Noto fonts on my system, an innocent match
pattern like "Cantarell 14" turns into a monster with a list of
300 family names after calling FcConfigSubstitute().
With this setup, every FcFontSort call takes 80-100 ms, which is
entirely incompatible with using FcFontSort for anything interactive.
And many font choosers render every font in itself, causing on average
one FcFontSort call per font.
On my system, it takes more than 20 seconds to open the GTK font
chooser dialog, with frequent stalls when scrolling.
This patch special-cases font families and replaces the list
walking for comparison with a hash table lookup. With this
patch, the FcFontSort time goes to ~10ms per call. Which is
still not good enough for calling it dozens of times when
scrolling, but a significant improvement.
Add a hash function that behaves like family
comparison: ignoring case and blanks. This
will be used to replace the list walking for
finding family matches with a hash table.
Make variants of FcStrCaseWalkerNext for the two
common cases, delim == NULL and delim == " ", to
speed things up.
These are inner loops, and having the conditions
as simple as possible helps.
As far as I can tell, fontconfig can recover from encountering an unknown attribute.
And unknown elements already print a warning instead of an error, so let's make this a warning too.
Nirbheek Chauhan
xiota
Akira TAGOH
Ben Wagner
Tim-Philipp Müller
James Lee
Xavier Claessens
Chun-wei Fan
Matthias Clasen
Jan Tojnar
Alan Coopersmith