[dev-servo] Fwd: Re: Fast path for text shaping--worth it?
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 To: Patrick Walton CC: John Daggett 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,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
Re: [dev-servo] Fast path for text shaping--worth it?
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 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 > To: Patrick Walton > CC: John Daggett > > 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,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
Re: [dev-servo] Fast path for text shaping--worth it?
Also, in Servo you could try doing parallel shaping, which should work well. I agree fully with what Jonathan said. Bypassing shaping is unlikely to make sense in the long run. 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
