[Webkit-unassigned] [Bug 95866] Refactor WebCore::FontData handling to clarify pointer ownership

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=95866





--- Comment #3 from Stephen Chenney <schenney at chromium.org>  2012-09-06 08:17:37 PST ---
Here's my analysis of FontData ownership and other class that hold pointers to it:

FontData allocated in CSSFontFaceSource either comes from the cache or is only custom.

All SegmentedFontData are custom fonts.

FontCache.cpp has a hash table with SimpleFontData in the value field. Note that this rules out SegmentedFontData from storage in the cache. If the font is retained, it adds it to the cache and will not remove it unless it's use count goes to zero. Otherwise, it puts it in the cache but also adds it to the inactive font list. The inactive font list is not cleared until purgeInactiveFontDataIfNeeded or purgeInactiveFontData, at which point the SimpleFontData is deleted. The FontCachePurgeProtector triggers font cache purging upon destruction.

However, FontCache::getFontData only puts FontData in the cache when the FontSelector::getFontData method returns 0. But, the CSSFontSelector code uses FontCache::getCachedFontData for all non-custom fonts. FontCache::getCachedFontData always adds the FontData to the cache and it's never custom data.

>From this we infer that FontCache owns non-custom FontData, and FontFallbackList owns custom FontData that DOES NOT COME FROM FontSelector. The "retains" flag seems consistent in this context.

CSSSegmentedFontFace has a HashMap where the values are SegmentedFontData*. These are not deleted by CSSSegmentedFontFace, which is good, but it is not clear that this table is always cleared when FontFallbackList prunes its tree. That would require calling CSSSegmentedFontFace::~CSSSegmentedFontFace(), CSSSegmentedFontFace::fontLoaded(CSSFontFace*) or CSSSegmentedFontFace::appendFontFace(PassRefPtr<CSSFontFace> fontFace). CSSFontFaceSource has identical issues to CSSSegmentedFontFace.

Who clears the HashMap in CSSSegmentedFontFace and CSSFontFaceSource when FontData is deleted? It must be the case that these objects must always destructed when the FontData is cleared. Otherwise we would see problems all over tha place that we do not see now.

GlyphPage holds an array of SimpleFontData*. This is cleared when fonts are purged from the GlyphPageTreeNode.

GlyphPageTreeNode holds a HashMap keyed on FontData*. Cleared in destructor and when font is purged.

SimpleFontData owns its derived font data and deletes it.

Are the SimpleFontData DerivedData members ever cached? No, allocated directly in platform layers, held in RefPtrs, and never held by anything else.

InlineFlowBox has a hash map of SimpleFontData (rendering). But this is only ever stack allocated.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.