Text quality vs speed
rocal...@gmail.com
rendering that avoids Uniscribe/Pango, disabling ligatures (and
kerning too, on Linux). It would be nice to have ligatures and kerning
on, but going through Uniscribe and Pango for everything would be a
significant slowdown for some users ... other users won't care,
though. (On Mac we're currently going through ATSUI for everything; we
could add a Latin-1 fast path if we want to, in which case these
considerations would apply to Mac too...) Here's my current thinking:
* Text in chrome documents should default to optimizing for
quality. We hardly ever need to layout massive quantities of text in
chrome. Also some system fonts on Vista really want ligaturization.
* Text in content documents should default to optimizing for
speed, for benchmarks and users with slow machines.
* But users, especially users with fast machines, should be able
to opt for quality.
* Perhaps if we dectect the user has a fast machine, we could set
them up for quality by default.
* We could also give authors control over quality, perhaps by
using the SVG text-rendering CSS property.
Any thoughts/suggestions?
Gervase Markham
> * Perhaps if we dectect the user has a fast machine, we could set
> them up for quality by default.
If we can reliably detect this, it seems like the best plan.
> * We could also give authors control over quality, perhaps by
> using the SVG text-rendering CSS property.
I'm not sure this is a good idea; we'll end up with this CSS property
scattered across the web like confetti, and even in three years where
everyone's machine is so powerful that we don't pay attention to it any
more, it'll still be a magic incantation.
Gerv
stu...@gmail.com
wrote:
I think this is right on. We should use quality in chrome and should
support a pref for text rendering. There are cases with certain fonts
that represent latin-1 text that simply don't work unless they use
ligatures, so I think we also need a CSS property to override the fast
path.
stuart
Benjamin Smedberg
> * Text in content documents should default to optimizing for
> speed, for benchmarks and users with slow machines.
I think that text over a threshold font size should go through the quality
path: quality reduction and miskerned text is much more noticeable in headlines.
Or if possible, automatically quality-path all headline text (this could be
done if you implemented the CSS property and added rules to html.css).
--BDS
Michael Vincent van Rantwijk, MultiZilla
People are still, even today and next year perhaps, using Windows 98,
and happily it seems, so this statement is not true.
stu...@gmail.com
Roc and I discussed this a while ago but I think it would be very
confusing to web authors if some text renders one way in certain
elements but differently in others.
stuart
Gervase Markham
>> and even in three years where everyone's machine is so powerful that
>> we don't pay attention to it any more, it'll still be a magic
>> incantation.
Three years, five years, whatever. The point still stands.
> People are still, even today and next year perhaps, using Windows 98,
> and happily it seems, so this statement is not true.
A) But they won't be using the version of Firefox we are discussing, as
it won't support Windows 98.
B) People shouldn't take Windows 98 anywhere near the Internet; it has
known remote security holes.
Gerv
Michael Vincent van Rantwijk, MultiZilla
> Michael Vincent van Rantwijk, MultiZilla wrote:
>>> and even in three years where everyone's machine is so powerful that
>>> we don't pay attention to it any more, it'll still be a magic
>>> incantation.
>
> Three years, five years, whatever. The point still stands.
Still stands? So why are people complaining about Windows Vista? Which
eats memory (not to mentioning Firefox) and other system resources,
simply because they are available now, and please note that industry
leaders recently asked Intel, AMD and IBM for more raw power.
>> People are still, even today and next year perhaps, using Windows 98,
>> and happily it seems, so this statement is not true.
>
> A) But they won't be using the version of Firefox we are discussing, as
> it won't support Windows 98.
Firefox is build on top of the mozilla platform and as such changes will
impact other vendors, but Firefox is where the money is thus...that'll
be your target, until someone else taps in by the end of the year with a
better alternative.
> B) People shouldn't take Windows 98 anywhere near the Internet; it has
> known remote security holes.
But they are never hit by these flaws it seems, presumably because
Google, et all, prevents them from visiting suspicious sites with
viruses and what not.
fantasai
> On Jul 2, 4:14 am, Benjamin Smedberg <benja...@smedbergs.us> wrote:
>> rob...@ocallahan.org wrote:
>>> * Text in content documents should default to optimizing for
>>> speed, for benchmarks and users with slow machines.
>> I think that text over a threshold font size should go through the quality
>> path: quality reduction and miskerned text is much more noticeable in headlines.
>>
>> Or if possible, automatically quality-path all headline text (this could be
>> done if you implemented the CSS property and added rules to html.css).
>
> confusing to web authors if some text renders one way in certain
> elements but differently in others.
I think using the fast path for certain *elements* but not for others would
be confusing and might encourage people to use those elements just to get
pretty text.
However, I don't think using the fast path for large font sizes (on all elements)
would be confusing.
~fantasai
Jeff Rose
goes through the fast path and then once the page is rendered you can
go back and beautify things. I've seen plenty of programs that do
this, and it never seemed to be an annoyance. (Of course a
preference could be used to select only fast path, only Pango, or
progressive rendering, so that the, ahem, dinosaurs on windows 98
machines could get their FireFix.) High quality text, especially
ligatures, would really make straight html an option for fancy media
outlets that have kept with PDF or even worse done header rendering
with flash.
-Jeff
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Gervase Markham
> What about doing a progressive rendering scheme, where everything goes
> through the fast path and then once the page is rendered you can go back
> and beautify things.
I assume we could only do this if the two paths were guaranteed to come
up with identical font metrics. Otherwise the layout might change on the
second pass, which would be irritating.
Gerv
Boris Zbarsky
> I assume we could only do this if the two paths were guaranteed to come
> up with identical font metrics.
That wouldn't happen. The whole point of the high-quality path is to get
kerning and ligatures. Kerning is pretty much guaranteed to change metrics.
Ligatures probably do as well.
-Boris
Vladimir Vukicevic
Yep, I agree -- authors already get different rendering at different
sizes. For example, ClearType kicks in and out depending on font
size, depending on your OS. In no cases will the rendering be
drastically different.
Now, discretionary ligatures are another issue and are where a CSS
property would come in useful, but that's less important.
- Vlad
rocal...@gmail.com
> rob...@ocallahan.org wrote:
> > * We could also give authors control over quality, perhaps by
> > using the SVG text-rendering CSS property.
>
> I'm not sure this is a good idea; we'll end up with this CSS property
> scattered across the web like confetti, and even in three years where
> everyone's machine is so powerful that we don't pay attention to it any
> more, it'll still be a magic incantation.
That may or may not happen: machines may not get much more powerful
any time soon, and we may want to support ever-fancier text rendering,
and the use of text in animations and so forth may place greater
demands on the software. In any case we can always choose to ignore
the property later.
I've filed bug 387969 on this. My proposal in there is to implement
the text-rendering property, allow the "auto" value to switch between
fast and high quality based on the actual text size, and set textboxes
and XUL elements to high quality.
Rob
Karl Tomlinson
> Currently on Windows and Linux we have a "fast path" for Latin-1 text
> rendering that avoids Uniscribe/Pango, disabling ligatures (and
> kerning too, on Linux). It would be nice to have ligatures and kerning
> on, but going through Uniscribe and Pango for everything would be a
> significant slowdown for some users ...
To get an indication of the speed penalty involved here, I
compared Tp2 page load times with and without
ENABLE_XFT_FAST_PATH_8BIT, on Linux (libpangoxft).
The baseline is the trunk source as at 2007-07-15 22:21 UTC,
which has ENABLE_XFT_FAST_PATH_8BIT defined.
mean stderror avgmedian
base 141.4 0.66 135.2
no XFT_FAST_PATH 153.3 0.90 148.1
+ no missing glyph search 155.6 0.77 153.2
The first two results are with ENABLE_XFT_FAST_PATH_8BIT defined
and undefined.
"mean" is the arithmetic mean of load times over 40 cycles of 40
different pages.
"stderror" is the standard deviation expected for the error in the
measurement of the mean load time of the 40 pages [calculated as
the standard deviation over 40 cycles of the mean load time of the
40 pages / sqrt(40 cycles)]. If I remember my statistics
correctly the 95% confidence interval for the mean is
approximately the measured mean +/- 2 standard errors.
So the 95% confidence interval for the difference that the
XFT_FAST_PATH makes is about 6 to 11 percent.
"avgmedian" is a value output by the Tp2 test. [It drops the
slowest page from each cycle, takes the median of the remaining
page times in each cycle, then drops the value for the slowest
cycle, and takes the mean of the remaining cycles.]
The Pango (non-XFT_FAST) path also handles missing glyph detection
and font fallback selection, which is not done in the
XFT_FAST_PATH. In an attempt to see if this had much impact on
the speed, I disabled the missing glyph search in
FontSelector::InitSegments to see if this had much impact on the
speed. This is the third result, which also has XFT_FAST_PATH
disabled.
Apparently any time saved by not doing the missing glyph search
ourselves was lost when Pango handles the missing glyph. The 95%
CI for the net time lost through skipping the missing glyph search
is about -1 to 4 percent (i.e. not statistically significant in
this test). However, there may still be room for an optimization
of the Pango path for ASCII text.