On Wed, Feb 12, 2014 at 5:00 PM, Patrick Walton <pcwal...@mozilla.com>wrote:
> On 2/10/14 12:41 PM, Robert O'Callahan wrote: > >> What exactly do you mean by "font collection loading"? If you ask the >> right >> questions I can explain how it works in Gecko :-). >> > > Sure thing. Sorry for the delay here, I needed to profile and > re-familiarize myself with Servo's code :) > > I'm on a Mac, so I'll describe it in terms of those APIs. The hot > font-related functions in Wikipedia flow construction are as follows: > > * `CTFontGetBoundingBox` - called during frame construction for text boxes > when we hit a font we haven't seen yet. I think this is for vertical align. > > * `CTFontGetAdvancesForGlyphs`/`CTFontGetGlyphsForCharacters` - core > shaping functions, called during text run construction, part of frame > construction, as part of a HarfBuzz callback. > > * `CTFontCollectionCreateMatchingFontDescriptors` - constructs the query > used to ask the OS which fonts are available. This is ultimately called > from Servo `FontContext::get_resolved_font_for_style()`, called during > frame construction for text boxes. > > * `CTFontManagerCopyAvailableFamilyNames` - gets the list of available > families from the OS. Called when we create the thread-local font context. > (There is one font context per frame construction thread.) > > So I guess my question is: Where does Gecko call the analogues to these > functions? > Obtaining the list of platform fonts is incredibly performance-sensitive. We have a gfxPlatformFontList object for this, which caches the font list indefinitely. When the system notifies us of a font list change, we rebuild our font list from scratch, but that's very rare of course. The tricky part is how to build this list without slowing down startup. The key thing is that we don't always need the list. We can look up simple fonts by family name without having a complete list of the platform fonts, and for each language we have a list of default font names that have a good chance of supporting the characters of that language; all that means we can render many pages without needing the platform font list. So, we build it incrementally after startup, off the main thread (as of recently, thanks to jdaggett). gfxPlatformFontList caches all relevant information about the fonts, especially the set of characters each font supports. These are needed so that when you encounter an odd Unicode character you can quickly find a font supporting that character. We did quite a lot of work to optimize the memory usage of those sets. The only other platform function that you really need for shaping is one to get the advances of glyphs --- for platforms that do platform-specific glyph hinting. You don't actually need this on Mac; we implement it only for D2D, GDI and Freetype, and we cache the results of the platform calls very aggressively. This is gfxFont::GetGlyphWidth/ProvidesGlyphWidths. I'm not sure why you need CTFontGetBoundingBox during frame construction... it seems more like a layout thing. In any case, we have all our font metrics fully cached in gfxFont, and we also cache the ink bounding box of individual glyphs when those are needed in gfxGlyphExtents. Don't forget to distinguish the generic font data (gfxFontEntry) from the font-at-a-specific-size-and-weight data (gfxFont), of course. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
