IIRC, Servo's text shaping code has implemented few if any of the caches that are in Thebes. I would recommend implementing them first (also, soon supporting RTL and complex text layout) before comparing to highly optimized text rendering.
On Sep 17, 2013, at 8:56 AM, Patrick Walton <pwal...@mozilla.com> wrote: > cc-ing the list here. This is relevant to the "shaping fast path" discussion > that came up in the meeting. > > Patrick > > -------- Original Message -------- > Subject: Re: Fast path for text shaping--worth it? > Date: Tue, 17 Sep 2013 09:02:34 +0100 > From: Jonathan Kew <j...@mozilla.com> > To: Patrick Walton <pwal...@mozilla.com> > CC: John Daggett <jdagg...@mozilla.com> > > On 17/9/13 01:21, Patrick Walton wrote: >> Hi Jonathan, >> >> Samsung pointed out that WebKit has a fast path for text shaping for >> text runs that are "simple" (all Latin text, I guess?) that does not >> call into HarfBuzz to perform shaping; instead such runs are passed >> directly to the underlying graphics subsystem to render. Is this >> something that Gecko has an equivalent for, and is it worth it in your >> view? >> >> Thanks! >> Patrick > > cc-ing John Daggett, who is currently looking into text performance in > various ways.... > > In Gecko, we used to have a distinction, at least on some platforms, > between a "fast" path that bypassed text-shaping features such as > ligatures and kerning, and a "quality" path that implemented these > features. We've dropped that (a couple years back, iirc?) so that all > text now goes through a "quality" path and receives the same layout > treatment. > > The main way we try to address the performance impact at the moment is > by caching "shaped words" on a per-font basis, to avoid the cost of > re-shaping the same word repeatedly (either when it occurs many times on > the page, or when we need to re-flow the page for any reason). Largely > because of this caching, I suspect, we didn't see any significant > performance impact when we simplified the text system to only have the > "quality" path. > > In practice, I think very little "normal" web content would be eligible > for a no-shaping fast path, if we want to maintain rendering quality; > we'd need to check that the font being used does not include any layout > features (including simple ligatures such as "fi" and "fl", or kerning > for pairs like "To" or "AV") that apply to the text in question. Most > fonts these days - even for plain Latin text - do have such features, so > they'd need the harfbuzz path. > > For a simple example, compare the rendering on OS X of > > data:text/html,<div style="font:16px Times New Roman">AWAKE! To Tell > You The Truth > > between Firefox (which applies the kerning defined in the font) and > Chrome/Safari (which don't) -- the Firefox rendering looks way better. > You can force Chrome or Safari to match Firefox here by adding the > "hint" text-rendering:optimizeLegibility to the style, but our position > is that authors should not have to do this in order to get good text > rendering; it should be the standard behavior. > > Determining exactly what text could safely be sent through a "fast path" > that bypasses harfbuzz shaping *without* loss of quality is tricky - > except for the corner case where the font simply does not have any > layout features at all. But in that case harfbuzz itself will be > relatively fast too, as it won't find much work to do. It's probably > true that we could get a (small) perf win by taking some shortcuts if we > detect that the text is purely 8-bit (hence no complex-script or > combining characters present) *and* the font being used has no layout > features to apply, but IMO the benefits in practice are likely to be > sufficiently minor (and rare) that it's unlikely to be worth the added > complexity. > > JK > > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
