If you don't care about linux browser side font issues you can skip this. I've been chasing Linux font metrics problems all week and wanted to send around a summary in case anyone has insight or opinions.
app/gfx/font on linux uses Skia for measuring metrics, and app/gfx/canvas uses Pango to draw the text. When rendering the text we often times clip to the height returned from font, which is the size returned from Skia. This means that if Skia returns a size smaller than Pango wants to draw at, we get clipping; which was in fact happening. In theory both Skia and Pango should be using the same font files so this doesn't happen, but in practice we get clipping. See http://crbug.com/20823 for one manifestation of this. My first attempt at fixing this was to change font to use Pango for measuring rather than Skia. This resulted in no clipping, but a huge performance regression (close to 2x). Why so big? ResourceBundle creates a number of fonts the first time you ask for one, which triggers asking for the metrics. Apparently asking Pango for the metrics is excruciatingly slow as compared to Skia. It turns out we really only need the metrics of one font at startup (tab heights). My second attempt delayed getting metrics until needed, which brought performance down, but still resulted in a slow down of ~10%. Better, but still no good. The slow down is entirely contributed to the call pango_context_get_metrics. It's worth noting that Gtk calls this function at times as well, so presumably our Gtk code hits this function at some point (if you have bookmarks bar open we'll hit it, or open preferences...). I then spent some time with a debug build of pango and a profiler. This was not terribly enlightening, the profiler attributed the extra time to libfontconfig. I then started tracing through pango code to see if I could locate where Skia and Pango diverge on getting metrics. I traced through some calls and these quickly ended up in Cairo. *SIGH* At that point I talked with Mike Reed and he suggested using the bounding box rather than the ascent/descent. Converting font to use this gets us much closer. For the default font on hardy we are dead on, but at some point sizes we are off by 1. For the time being I'm going with using the bounding box rather than ascent/descent. I believe using pango to get metrics is the right thing to do, but a 10% startup is hard to justify. -Scott --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
