Front-end performance optimized CSS animations

Recently read a few html5rocks on the CSS3 animation performance optimization of the article, learned a lot, here to record, where the knowledge is from these two articles, I just intercepted one of the more concerned about the content, the original address of the high performance Animations and accelerated Rendering in chrome principle

Modern browsers when using CSS3 animations, the following four scenarios are more efficient to draw: * Change position * Change size * rotate * Change transparency

Layer? Redraw? Reflow and re-layout? Layer reorganization?

The first thing to know about the CSS layer concept (Chrome browser)

When a browser renders a page, it divides the page into layers with a large number of layers, one or more nodes on each layer. When rendering the DOM, the browser's work is actually: 1. Gets the DOM and splits it into multiple layers 2. Calculates the style result (recalculate style--style recalculation) for each layer's node 3. Generate graphs and positions (layout--reflow and re-layout) for each node 4. Fills each node drawing into the layer bitmap (paint setup and paint--redraw) 5. The layer is uploaded as a texture to GPU 6. Match multiple layers to create a final screen image on the page (Composite layers--layer reorganization)

A layer is created in chrome if any of the following conditions are true: * 3D or Perspective transform (Perspective transform) CSS Properties * nodes with accelerated video decoding * <video> node with 3D (WebGL) context or accelerated 2D context <canvas> * Hybrid plugins (such as Flash) * CSS animations for your own opacity or elements that use an animated WebKit transform * elements with an accelerated CSS filter * element has a descendant node containing a composite layer (an element that has a child element in its own layer) * element has a z-indexa sibling element that is lower and contains a composite layer (in other words, the element is rendered above the composite layer)

It is important to note that if an element in the layer needs to be redrawn, the entire layer will need to be redrawn. For example, a layer contains many nodes, with a GIF, and each frame of the GIF will return to the other nodes of the entire layer, and then generate the final layer bitmap. So this requires a special way to force the GIF to belong to its own layer ( translateZ(0) or translate3d(0,0,0) ), CSS3 's animation is the same (fortunately most of the browsers themselves will create a layer for the CSS3 animation node)

Layers and CSS Animations

To simplify the process above, each frame animation browser may need to do the following: 1. Calculates the style result that needs to be loaded onto the node (Recalculate style--style recalculation) 2. Generate graphs and positions (layout--reflow and re-layout) for each node 3. Populate each node in a layer (paint setup and paint--redraw) 4. Group layers onto the page (Composite layers--layer reorganization)

If we need to improve the performance of the animation, we need to reduce the work that the browser needs to do when the animation is running. The best case is that changing the properties of only the impression layer's combination, transformation ( transform ) and transparency ( opacity ) is the case

Modern browsers like Chrome,firefox,safari and opera use hardware acceleration for transformations and transparency, but ie10+ is not sure if hardware acceleration

Properties that trigger a re-layout

Some nodes, when you change him, will need to be re-layout (which also means that the location and size of other affected nodes need to be recalculated). In this case, the larger the affected DOM tree (visible nodes), the longer it takes to redraw, and the longer the time to render a frame of animation. So try to avoid these attributes

Some common changes trigger the properties of the re-layout: Box model related properties trigger a re-layout: * Width * height * padding * margin * display * border-width * border * min-height

Positioning properties and floats also trigger a re-layout: * top * Bottom * left * right * position * float * clear

Changing the internal text structure of a node also triggers a re-layout: * text-align * overflow-y * font-weight * overflow * font-family * line-height * vertival-align * White -space * font-size

So many of the common properties trigger the re-layout, and as you can see, they are characterized by the possibility of modifying the size or position of the entire node, which will trigger a re-layout

Do not use CSS class names for status tags

If you use CSS classes in your Web pages to flag nodes, the redraw and re-layout of nodes will be triggered when the status tag classes of those nodes are modified. So it's expensive to use CSS classes on nodes to do state comparisons.

Properties that trigger repainting

Only properties that trigger redraw when modified are: * Color * border-style * border-radius * visibility * text-decoration * background * background-image * back Ground-position * background-repeat * background-size * outline-color * outline * outline-style * outline-width * Box-shad ow

As you can see, these properties do not modify the size and position of the node, and naturally do not trigger the re-layout, but the render effect inside the node is changed so that only a redraw is required.

The phone is slow even if it's redrawn.

When redrawn, these nodes are loaded into the GPU for repainting, which has a significant impact on mobile devices such as mobile phones. Because the CPU is not as good as a desktop or laptop, painting the lich takes longer. And there is a large bandwidth limit between the CPU and the GPU, so the upload of textures takes a certain amount of time

Attribute transparency that triggers a layer reorganization does not trigger redraw?

It is interesting to note that there is no (transparency) in the above properties that trigger repainting opacity , is it strange? In fact, after the change in transparency, the GPU simply reduces the alpha value of the previously drawn texture to achieve the effect and does not require a whole redraw. But this premise is that the modification opacity itself must be a layer, and if there are other nodes under the layer, the GPU will also transparently

Forcing the browser to create a layer

In Blink and WebKit browsers, when a node is set to a related transition effect or animation of transparency, the browser uses it as a separate layer, but many developers use translateZ(0) or translate3d(0,0,0) go to make the browser create layers. This way, you can eliminate the layer creation time before the animation starts, making the animation start as soon as possible (creating layers and drawing layers is slower) and not exporting mutations with antialiasing. This method, however, requires moderation, or it can cause a crash if too many layers are created

Anti-aliasing in chrome

In Chrome, non-root layers and transparent layers use grayscale antialiasing instead of subpixel antialiasing, and this effect can be significant if the antialiasing method changes. If you plan to preprocess a node instead of waiting for the animation to start, you can do so by forcing the browser to create layers

Transform transformation is your choice.

We transform can modify the node's position, rotation, size and so on through the node. We usually use the left and top properties to modify the position of the node, but as mentioned above, left and top will trigger the re-layout, the cost of the modification is quite large. Instead, the better way is translate to use this, which does not trigger the re-layout

A comparison between JS animation and CSS3 animation

We often face a choice between using JavaScript animations or using CSS animations, which are compared in the following two ways

JS Animation

Cons: JavaScript runs in the main thread of the browser, and there are many other JavaScript, style calculations, layouts, drawings, etc. that need to be run to interfere with it. This also causes the thread to block, causing the drop frame to occur.

Pros: JavaScript animations are different from CSS pre-defined animations that can be controlled during their animation: Start, pause, Replay, Abort, and cancel are all possible. And some animation effects, such as parallax scrolling effect, only JavaScript can be done

CSS Animations

Disadvantage: lack of strong control ability. And it's hard to combine things in a meaningful way, making animations complex and prone to problems. Pros: The browser can optimize the animation. It can create layers, if necessary, and then run outside the main thread.

Prospect

Google is currently exploring multi-threaded (Web Workers) via JS to provide better animations without triggering re-layout and style recalculation

Conclusion

Animations give the page a rich visual experience. We should try to avoid using properties that trigger re-layout and redraw to avoid losing frames. It is best to declare the animation in advance so that the browser can optimize the animation in advance. Due to GPU involvement, the best properties for animating now are as follows: * opacity * translate * rotate * scale

There may be new ways to use JavaScript to make better, unrestricted animations without worrying about the main thread's blocking problem. But before that, think about how to make a smooth animation.

Front-end performance optimized CSS animations