Compare PAG to Lottie from the decoded render level

Recently, due to business needs, we need to investigate the well-known animation rendering framework in the industry. After some time of research and exploration, I focused my attention on two good animation frames. One is the well-known Lottie and the other is Tencent’s PAG.

Lottie is a well-known open source animation framework of Airbnb. After making animation through AE, it exports the JSON file of animation through the attached plug-in BodyMovin. On the end through JSON parsing rendering.

Lottie includes not only the on-side rendering SDK, but a complete animation workflow.

Portable Animated Graphics (PAG) is a complete animation workflow solution independently developed by Tencent.

I will evaluate which framework is the better choice for our business through the following research.

workflow

Let’s start by looking at a simple process using Lottie.

PAG process.

As can be seen from the flow charts of the two frameworks, the workflow is broadly similar, as shown in the following

  • Animation generated by AE

  • It comes with an AE plug-in, which allows you to export animations

    • Lottie’s bodymovin
    • PAG of PAG Exporter
  • preview

  • The export file

  • The rendering SDK on the end

The configuration file

Workflow is broadly similar. So I focused on the obvious differences between the two. That is, the configuration file exported by AE.

  1. Lottie chose JSON
  2. PAG selects a custom binary similar to protocolBuff.

This article will focus on the performance of both in terms of configuration file size and parsing performance.

Json configuration file for Lottie and PAG binary configuration file

Let’s start with a simple animation.

The general process of animation is as follows:

  • 0s to 3s, the scale attribute value changes from 100% to 50%.
  • From 3s to 6s, the scale property value changes from 50% to 100%, and the animation is completed.

Lottie json

The exported JSON file is as follows.

PAG

Since PAG generates binary files, you need the corresponding software PAGViewer to view them.

I won’t show the PAG export file here.

File size comparison

From the same animation file that we just generated.

  • The JSON file exported by Lottie is approximately 5KB.
  • The binary file exported by PAG is only 2kb.

Almost 60% of the size is missing.

Of course, isolated cases are not sufficient proof. I found similar benchmarks through research. The results are as follows.

As you can see, PAG has a large advantage in file size and compression ratio for exported configuration files. I think the possible reasons are as follows: PAG uses a binary data structure to store animation information. Binary data structures can easily assemble any resource from a single file and can be decoded tens of times faster than the JSON text data used by Lottie.

In terms of file size, PAG achieves a very high compression rate by taking advantage of the characteristics of animation files themselves. By skipping the storage of large default values and using dynamic bits for compact storage, the same animation content can reduce the file size by about 50% on average compared to the same type of scheme.

Why are animation files generated by PAG so small

This made me very interested. I have read the documents related to PAG, which are summarized as follows.

  1. The files generated by PAG are pure binaries and are parsed using their own parsing engine
  2. Because the binary format is adopted, redundant fields, which are unavoidable in JSON format, are avoided
  3. PAG uses dynamic bit compression, so the compression ratio is extremely high
  4. PAG also supports image and audio information encoding

So in this aspect of animation files, PAG is definitely the better choice

Rendering performance

After researching Lottie and PAG’s underlying rendering mechanism. Their differences are roughly as follows.

The implementation of Lottie and rendering layer depends on the platform side interface, so different platforms may support different AE features, inconsistent rendering effects and other problems. The PAG rendering level is implemented by C++, and all platforms share the same set of implementation. The platform side only encapsulates the interface call and provides the rendering environment, so all PAG platforms support the same features and the same rendering effect. Lottie’s BodyMovin does not support all AE features, nor does it support text, sequence frames, etc.

So initially, PAG performance should be better. But from the perspective of research alone is not rigorous, so it still needs actual testing to prove.

Vector animation rendering performance

Several important indicators can be found.

  1. File decoding time
    1. Lottie’s JSON has a huge disadvantage over PAG’s binaries, being decoded almost 20 times faster than PAG’s
  1. First frame rendering takes Lottie 6 times less time than PAG
  2. The rendering time per frame is similar
  3. Lottie lags PAG by almost nine times in total time
  4. Memory is close to memory

Different end rendering effects

The rendering effect of different ends refers to whether the same animation effect can be obtained from the same animation file on iOS, Android or Web.

The entire animation scheme of PAG is developed based on C++ cross-platform architecture. It has been restored from the animation interpolator at the bottom to the timeline and layer rendering tree system at the top. Although the development cost is high, all ends share the same set of code, which naturally ensures cross-end rendering consistency.

However, Lottie adopts the development strategy of using native language on each end, which results in the consistency of rendering effects on different ends due to the differences of platforms. So the multi-endpoint consistency of PAG is better here.

Different strategies for time static intervals

In the special effects of animation files, in fact, most of the animation materials are not actually changing in the whole time axis, and there are more or less some static sections of the picture. So, there’s actually a lot of room for optimization. Here I investigate the different approaches of the two frameworks.

  • When PAG encounters these static intervals when refreshing, it returns directly to the animation content of the previous frame, automatically skipping any repeated drawing. In the extreme case, let’s say you have a one-minute animation that actually stays still the entire time. It acts as a static image to the PAG, with zero overhead for the entire refresh process.
  • In Lottie’s scheme, the entire refresh process is a total overhead because it clears the screen and refreshes every frame.

This means that PAG has a lower overhead than Lottie in terms of rendering performance if the animation has a lot of rest intervals.

Web Side Support

Aside from iOS and Android, the Web is an important platform. Anyone familiar with Lottie knows that Lottie has a lot of so-called optimization techniques on the Web side, which in some ways are what Lottie should have avoided.

We can compare the two different approaches to web implementation.

  • On the Web side, Lottie has been re-implemented using HTML, CSS, and Javascript from the Web.
  • PAG’s internal C++ layer implements texture rendering, anti-aliasing, gradient, blend, and other functions through OpenGL ES, which can also be applied to the Web layer without repeated implementation of web-related technologies. The specific scheme is to compile C++ code into WebAssembly and run it on the Web, using Emscripten (emscripten.org/) to achieve compilation. LibPAG is a static library compiled by CMake, and then a wASM file is generated by emCC linking the static library with the glue layer code.

As you can see, PAG also achieves high performance at the web level because it compiles C++ code to run in WebAssembly, but Lottie uses a native three-piece suite for web side animation, which is often limited in performance.

conclusion

In the whole workflow, because PAG uses C++ for self-research in file generation and decoding, including using C++ as the underlying rendering tool, rendering on the end also keeps relatively consistent rendering effect.

It can be said that the workflow of PAG system can achieve better results than Lottie in terms of user experience, and PAG will also be open source on January 14. Interested partners can also try it after reading this article.

Liverpoolfc.tv: pag. IO /

Official QQ group: 893379574