HN Explorer

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

5 points by emilyst ↗ HN
Comparison:

Firefox: http://drop.emily.st/s/Screen%20Shot%202013-09-15%20at%2013.34.33.png

Chrome: http://drop.emily.st/s/Screen%20Shot%202013-09-15%20at%2013.34.14.png

8 comments

[ 3.3 ms ] story [ 32.6 ms ] thread
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

bluedevmonkey
they didn't fix that issue since 2009. - another reason to use firefox. I've encountered that while designing a pixel-perfect website where firefox just give me the expected results while chrome hadn't the same results, didn't look good. sucks, but as a webdev you just have to accept it and work-around.
emilyst
The internet is lousy with information about Windows Chrome. OSX seems to be incorrect for no good reason. (I do note that WebKit seems to be the culprit here. Safari behaves the same way.)
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

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

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.