Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)
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? Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)
> * `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.) I think these we can stuff into an Arc and share. At some point the system may get new fonts added, at which point we'll need to create and pass new ones. It seems a little silly that we recalculate the font list and all the font groups every time, but it's mostly that way because we never had a reason to mess with it until now. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)
On 2/11/14 8:04 PM, Jack Moffitt wrote: * `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.) I think these we can stuff into an Arc and share. At some point the system may get new fonts added, at which point we'll need to create and pass new ones. It seems a little silly that we recalculate the font list and all the font groups every time, but it's mostly that way because we never had a reason to mess with it until now. Need to check whether these are OS objects, and if so, whether they're thread safe on all platforms. Linux fontconfig in particular is particularly bad, as we've discovered. (You need a lock around the whole thing unless you have a *very* recent version, newer than the one in many distros.) :( Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)
> Need to check whether these are OS objects, and if so, whether they're > thread safe on all platforms. Linux fontconfig in particular is particularly > bad, as we've discovered. (You need a lock around the whole thing unless you > have a *very* recent version, newer than the one in many distros.) :( Even if they aren't, we need a limited amount of info and it seems reasonable that we could cache it in the FontList data. I believe this is only used to figure out what specific font we want from a description. Once we have a font list, I don't think we actually need to talk to the OS anymore except to get the specific font. Also, I think you're thinking of Freetype not fontconfig as being thread-unsafe; perhaps they both are, but the issue I remember from recent hsitory was with Freetype. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)
On Wed, Feb 12, 2014 at 5:00 PM, Patrick Walton 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
