Jonathan Kew [:jfkthame] Assignee
	Description • 7 years ago

As a temporary (stack-based) helper, gfxFT2LockedFace doesn't need to hold a strong reference to the gfxFT2FontBase. Doing so causes unnecessary refcount twiddling.

This is particularly troublesome because gfxFT2LockedFace is used from within the gfxFontconfigFont constructor (via gfxFT2FontBase::InitMetrics), at which point the font being constructed has a refcount of zero. This means that using gfxFT2LockedFace to lock and access the FT_Face will bump the refcount to 1; then as the gfxFT2LockedFace goes out of scope again, the font's refcount drops back to zero; so gfxFont::Release figures we're done with the font and adds it to the gfxFontCache expiration-tracker list for eventual destruction -- though in practice we'll almost immediately bump its refcount again, when assigning the newly-created gfxFontconfigFont to a refptr somewhere, and take it back out of the expiration tracker. All that is a bunch of wasted work, AFAICS.

	Jonathan Kew [:jfkthame] Assignee
	Comment 1 • 7 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b186d396550b1a4099f5b18c62adcc2cd47b8dd7

	Jonathan Kew [:jfkthame] Assignee
	Comment 2 • 7 years ago

AFAICS, it should be safe to simplify like this.

	Jonathan Kew [:jfkthame] Assignee
	Comment 3 • 7 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/ffc8b060039e2edb00174b71e02448b68f135239
Bug 1393185 - Annotate gfxFT2LockedFace as a stack-based helper, and avoid touching the refcount of the font. r=lsalzman

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 4 • 7 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/ffc8b060039e