

Ask HN: On OS X, why does Firefox render fonts more readably than Chrome? - emilyst

Comparison:<p>Firefox: http:&#x2F;&#x2F;drop.emily.st&#x2F;s&#x2F;Screen%20Shot%202013-09-15%20at%2013.34.33.png<p>Chrome: http:&#x2F;&#x2F;drop.emily.st&#x2F;s&#x2F;Screen%20Shot%202013-09-15%20at%2013.34.14.png
======
bhauer
Sorry, I don't know the answer on OSX. But I do know that on Windows, Chrome
still does not include DirectWrite support, so font render much worse than in
Firefox. But hey, it's only been about four years since DirectWrite became
available.

This is one of the chief reasons I've never been a Chrome user. The font
rendering is bad. It doesn't use a subpixel letter positioning algorithm and
the kerning is just plain poor.

See
[http://code.google.com/p/chromium/issues/detail?id=25541](http://code.google.com/p/chromium/issues/detail?id=25541)

~~~
cabbeer
I don't know how google has gotten away with such shitty font rendering on
WinChrome for so long. The difference is instantly noticeable when comparing
to Firefox or IE. Is there an official reason for it or they "just haven't
gotten around to it yet"?

~~~
unconed
There's multiple answers, and multiple differences in the original image:

1) Firefox supports kerning, i.e. variable space between particular letter
pairs such as "TA" where you otherwise get unsightly gaps. WebKit/Blink does
not. Compare e.g. "Welcome" and notice the space between the 'W' and the 'e'
is larger on Webkit/Blink:
[https://en.wikipedia.org/wiki/Main_Page](https://en.wikipedia.org/wiki/Main_Page)

2) Most OSes support sub-pixel anti-aliasing, which creates the discolouration
at the edges of letters by anti-aliasing the RGB channels individually. This
means the text is being rendered as if every RGB channel has its own
transparency channel, which GPUs do not support as a native image format. When
browsers use hardware accelerated compositing, they flatten the page into RGBA
layers and compose them on the GPU. Any layer which consists of text on a
transparent background cannot do sub-pixel anti-aliasing this way. Firefox is
much less aggressive in using GPU layers, creating higher quality text, but
using more CPU rendering, the slow kind.

3) On OS X, when using subpixel AA, the text is blended with gamma correction,
in linear RGB (i.e. with correct brightness). When not using subpixel AA, the
text is blended in sRGB (with non-linear brightness). This difference is why
setting an opacity on text can cause it to suddenly look much thinner.

See: [http://acko.net/files/dump/aa.png](http://acko.net/files/dump/aa.png)

sRGB is your normal screen's color space. Linear RGB is the color space you
want to do color operations in.

If you invert the RGB values in sRGB, then non-subpixel AA looks the same
white-on-black and black-on-white. But the white-on-black looks much thinner.

If you invert the RGB values in Linear RGB, then the subpixel AA looks the
same in both cases, and the text looks equally bold white-on-black or black-
on-white.

Source: Been writing graphics algorithms for 20 years. Linear vs sRGB is
standard industry practice in gaming nowadays. On the desktop, it's still
mostly ignored.

------
fuzzywalrus
Chrome/Safari support subpixel rendering, using OS X's font renderer. Subpixel
rendering works well for black on white but looks awful in reverse

See: [http://www.usabilitypost.com/2012/11/05/stop-fixing-font-
smo...](http://www.usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/)

------
X4
It's because Firefox implements it's own text-rendering engine. I don't know
if chrome uses the OS API for text-rendering or has it's own text-rendering
engine too.

~~~
bob_george33
Chrome uses the OS API for text rendering afaict.

[http://arstechnica.com/apple/2013/08/rendering-bug-
crashes-o...](http://arstechnica.com/apple/2013/08/rendering-bug-crashes-os-x-
and-ios-apps-with-string-of-arabic-characters/)

