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
