This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
Cairo would normally query both the advance and other metrics at the same time,
then store them in a glyph cache sitting on each cairo_scaled_font_t any time
any of the extents were queried. Each cached scaled glyph metrics would require
about 150 bytes of space and could thus use a horribly large amount of memory
when a lot of glyphs were being used within a scaled font.
This tries to duplicate the behavior of querying and storing both advance and
bounds at the same time to effectively cut the number of glyph loads in half
for most cases. This should only add another 8 bytes per hash entry to store
the cached bounds, thus putting us way ahead on memory usage compared to what
Cairo did under the hood.
Further, Cairo would keep around cairo_scaled_font_t's in a holdover cache
even after there are no existing references to them and the owning gfxFonts
have long since died. This gives an artificial boost in successive runs of the
benchmark, while not aiding in the performance of the first run. I don't
believe the extra memory use would be justified to reproduce that particular
behavior, especially since our expectations are that the glyph cache for
a gfxFont dies when the gfxFont itself dies from the gfxFontCache.
In any case, this should at least significantly boost our glyph metrics
performance on a cold start, with the caveat about the warm start case.
Differential Revision: https://phabricator.services.mozilla.com/D46726
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
With bug 1509358 having landed we don't need a draw target in a bunch of
places. This removes it from those places.
Differential Revision: https://phabricator.services.mozilla.com/D15481
--HG--
extra : moz-landing-system : lando
This rearranges how synthetic-bold use is determined in the font selection
& rendering code. Previously, we would decide during the font-selection
algorithm whether we need to apply synthetic-bold to the chosen face, and
then pass that decision through the fontgroup (storing it in the FamilyFace
entries of the mFonts array there) down to the actual rendering code that
instantiates fonts from the faces (font entries) we've selected.
That became a problem for variation fonts because in the case of a user
font, we may not have downloaded the resource yet, so we just have a "user
font container" entry, which carries the descriptors from the @font-face
rule and will fetch the actual resource when needed. But in the case of a
@font-face rule without a weight descriptor, we don't actually know at
font-selection time whether the face will support "true" bold (via a
variation axis) or not, so we can't reliably make the right decision about
applying synthetic bold.
So we now defer that decision until we actually instantiate a platform font
object to shape/measure/draw text. At that point, we have the requested
style and we also have the real font resource, so we can easily determine
whether fake-bold is required.
(This patch should not result in any visible behavior change; that will
come in a second patch now that the architecture supports it.)
Jonathan Kew
Lee Salzman
Daniel Varga
Cosmin Sabou
Jean-Yves Avenard
Jeff Muizelaar
Tooru Fujisawa
Sylvestre Ledru
Carsten "Tomcat" Book
Nicholas Nethercote
Ehsan Akhgari
John Daggett
Jonathan Watt
Jonathan Kew
Nicholas Cameron
Gervase Markham
Bas Schouten
Michael Wu
Zack Weinberg