Secrets of Browser font rendering

When it comes to Web performance, the front-end engineers naturally react to Yahoo's 30+ optimization rules. These rules can load a Web page from the original seconds or even less than more than 10 seconds to 3s or even 1s. When a full interface is displayed to the user, the content is communicated to the user through different fonts, images, and multimedia. It is equally important for users to see web pages within 1s and to use them for a few minutes or even dozens of minutes to stay on the web. As an important part of the content bearer information, the use of fonts or fonts that are not "appropriate" is not friendly to the user because of rendering, which may cause unnecessary loss of user. This article describes the browser's font rendering, and I hope that colleagues who have not touched the font rendering can learn about font rendering in this article.

First look at the screenshots under different browsers:

It is obvious that the Chrome35 screenshot of the non-horizontal strokes than the IE11 and Firefox30 screenshots have obvious sawtooth.

The ideal font has a smooth edge transition, and when displayed on the screen, the font grid (rasterization) needs to be a pixel. Using Black-and-White rendering does not reflect the details of the font, causing the edge to appear jagged (jagged) is not smooth. To address this problem, the font rendering engine uses the following methods for smoothing (antialiasing): Grayscale (grayscale) rendering, Subpixel (sub-pixel) rendering.

Rendering methods

Grayscale rendering is a method of controlling the brightness of pixels on the font contour to reach the original shape of the font.

Sub-pixel rendering utilizes the LCD screen (the LCD screen) where each pixel is made up of R, G, b three sub-pixel color and brightness mixed into a complete pixel color of this principle, the font profile of the pixel points by three sub-pixel embodiment to achieve the original shape of the method. Compared to grayscale rendering, the resolution is magnified three times times in the vertical direction, so the rendering is better, but the memory consumption is also more. Therefore, in the mobile phone screen, in order to reduce CPU overhead, the font rendering method is not adopted, but the use of grayscale rendering.

Rendering APIs in the operating system

The operating system OS provides APIs that support different font rendering methods. Under Windows is the GDI (Graphics Device Interface) and Directwrite,os x is quartz.

GDI is divided into GDI grayscale and GDI ClearType. The former is a grayscale rendering API, and the latter is a Subpixel rendering API. Because the GDI ClearType does not smooth the font vertically, the edges are not smooth when the font is large. To compensate for the lack of GDI ClearType, Ms implements the Directwrite API, which adds vertical smoothing on the basis of GDI ClearType.

But! The font rendering API is chosen by the browser manufacturer itself!

Using the same color, the color depth of the senses is: black and white rendering >grayscale>sub-pixel.

CHROME35/36 uses GDI ClearType, so there is a burr on the edge when the font is large, and the directwrite that FF30 uses does not have such a problem. As shown in the following illustration:

According to the above two figures can be found that Chrome's font rendering effect is not good for Firefox. One way to reduce the difference between chrome and ff/ie is to use-webkit-text-stroke:0.5px, which is a bit thick if you use 1px.

Although the hack makes the edges of chrome fonts smoother, the fonts look "blurry" in the WebKit kernel browser.

How common fonts are rendered in the browser

From using Microsoft Yahei, Tahoma, and Arial fonts, you can see that in Chrome35, 49px characters are much smoother than 48px edges due to conversion to GDI grayscale rendering. GDI grayscale has a better rendering effect than GDI ClearType when the font is large.

In practice, there is a significant difference between the word weight of 17px and 18px, as in the case of tahoma/arial fonts. This phenomenon is related to font design, simply put, the font itself adjusts the pixel of the typeface and stroke before the browser renders the font. For more details, please refer to a closer look at TrueType hinting.

Start the Directwrite in Chrome

Enable the experimental Directwrite font rendering system under Chrome://flags: #enable-direct-write The fonts below 48px are rendered sub-pixel. Only for test environments! (Need to restart Chrome)

Chrome37 Beta removes this feature from the experimental feature and will implement the font rendering in Chrome37 using the Directwrite API, believing that the browser font rendering differences mentioned above in Chrome37 are resolved.

Rendering of font formats in different browsers

font-smoothing:subpixel-antialiased | antialiased;

Corresponds to Sub-pixel and grayscale.
has been abolished!

Font-weight:bold;
CHROME35, IE7/8: Consistent with normal font rendering (including numbers and letters);
Ie9+/ff30:grayscale, some simple Chinese fonts retain their original rendering.

Font-style:italic;
CHROME35, IE7/8: Consistent with normal font rendering;
Ie9+/ff30:sub-pixel rendering.

Opacity: Property value <1
Chrome35:sub-pixel rendered font "degraded" for grayscale rendering;
IE9+/FF30: Remain unchanged

Transform 2D

Transform:rotate (n);
N=90*k deg (k= integer) to maintain the rotated font rendering;
Others,sub-pixel rendering. Chrome35 in 48px+ for grayscale rendering.
Transform:scale (X,y); Related to the font size M. Take SimSun as an example, specifically as follows:

CHROME35:
X*y*m<12, Chrome35 sub-pixel rendering;
12<x*y*m<=48*48=2304 sub-pixel Rendering; x*y*m>2304 grayscale rendering, 12PX-24PX has a range of black and white rendering (Tahoma is 12px-16px).

FF30, ie9+:
m*m*n<=99*99=9801 sub-pixel Rendering; m*m*n>9801 grayscale Rendering.

Transform:skew (n);
N=90*k deg (k is an integer) to maintain an italic font rendering;
Others, sub-pixel rendering. Chrome35 in 49px+ for grayscale rendering, ie9+, FF30 in 100px+ for grayscale rendering.

Transform 2D & Transition

Motion: Take 12px as an example: under Chrome35 and FF30, the font in motion is grayscale rendering;
Campaign end: Chrome35, FF30, ie9+ are sub-pixel rendering.
From the start to the end of the movement produced two rendering changes (Sub-pixel to Grayscale,grayscale to Sub-pixel) will appear "flash" phenomenon.

Transform 3D

When the elements are rendered in the GPU, the fonts in chrome35+ are grayscale rendered, IE11 and FF30 remain sub-pixel rendered unchanged. If the parameter in the transform value function (such as translate3d (), scale (), rotate (), etc.) is not an integer, it can result in a font blur. The font blur appears in items that use Iscroll to simulate scrolling. The following is a restore of the problem:

-webkit-transform:translate3d (1.5px, 1.5px,0);

-webkit-transform:translate3d (1px, 1px,0);

The use of transform in Chrome 36 does not require a-webkit-prefix!

In order to prevent the above ambiguity, the Math.Round ()/math.ceil ()/math.floor () in JS can be used to make it an integer.

When perspective () value is added, Firefox30 rendering is different.

Transform:perspective (1px) Translate3d (1.5px, 1.5px,0); the element acting in FF30 is grayscale rendering.

Transform:perspective (1px) Translate3d (1px, 1px,0); The elements acting in the FF30 are sub-pixel rendering

E11 are sub-pixel rendering.

In this case, the use of Opacity<1 's statement, ie10+ for grayscale.

The effect of Chrome transform:perspective () on the elements behind the document

chrome35+, when a perspective () is declared in transform, it is still affected by the declaration when the element that declares the transform enters the area of the layer-borders of the element that declares the action. Declaring the overflow part of the action element also affects the following elements. The inner text of the synthetic render layer goes into the GPU rendering.

Start show composited layer borders, the results of the test in Chrome are screenshots:

Summarize

Font rendering is related to the operating system, browser, font format, and CSS properties. This article highlights some of the differences between font rendering and ff/ie in Windows Chrome and solutions to mitigation/resolution problems. Chrome is lagging behind ie/ff in font rendering, but previously the official blog said that Chrome 37 would be implemented in Windows using Directwrite api,chrome in font rendering will catch up with browsers such as IE/FF, the above differences will also reduce or even disappear.