This reverts the per-glyph-run optimization landed in bug 1816299, and replaces it with a per-glyph version
that will work within a long run of glyphs in a single font, as well as across the glyph runs in a mixed-font textrun.
To minimize the cost of the check, rather than retrieving individual glyph bounds, we use the overall font extents.
(Note that this uses the bounding box min/max coordinates from the 'head' table, which may exceed the typographic
ascent/descent of the font, and the advances of the glyphs; we care about the ink extents, not typographic size.)
Differential Revision: https://phabricator.services.mozilla.com/D170058
This patch reverts our behaviour closer to how we worked prior to bug
1780193. Parts of bug 1780193 remain because they are necessary to
ensure there are no race conditions when interacting with the cache from
multiple threads.
Now we remove fonts from the expiration tracker when there are strong
references remaining to the object. When the last strong reference is
cleared, we readd the font to the expiration tracker. A lookup will
remove it from the tracker (and creates a strong reference). If it
expires from the tracker, it is then destroy. There are several race
conditions we need to manage because the refcount can be updated without
holding the gfxFontCache mutex.
Differential Revision: https://phabricator.services.mozilla.com/D156716
In this patch, we make gfxFont use normal AddRef/Release semantics, and
instead now hold a strong reference to it inside the cache. At all times
a font should be in the expiration tracker, and whenever a lookup is
performed, we mark it as used.
When the tracker attempts to expire an entry, we check to see if the
only strong reference is inside the cache itself. If so, it is deleted.
If not, we mark it as used again instead of expiring it.
This has the advantage of making gfxFont::Release cheaper when there is
only one outstanding reference left outside the cache. It used to
acquire the gfxFontCache mutex in order to reinsert the font into the
expiration tracker when the last strong reference was cleared. This is a
very common case since the typical use case is only the main thread is
interacting with the cache, one font reference at a time.
This does not completely restore us to the previous performance
observed, but it does reclaim half of the original design benefit while
remaining threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D153110
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
The loaders need to be destroyed on the main thread. Assertions for
gfxUserFontSet and gfxFontFamily need to be updated for workers.
Depends on D151342
Differential Revision: https://phabricator.services.mozilla.com/D151343
The loaders need to be destroyed on the main thread. Assertions for
gfxUserFontSet and gfxFontFamily need to be updated for workers.
Depends on D151342
Differential Revision: https://phabricator.services.mozilla.com/D151343
Jonathan Kew
Noemi Erli
Norisz Fay
Cristian Tuns
Butkovits Atila
Masatoshi Kimura
Andrew Osmond
Shravan Narayan
Iulian Moraru
Sandor Molnar
Fabrice Desré
Andreea Pavel
criss