Briefly comment on the rendering algorithm of Adobe's Flash Player

Some time ago, I saw an article on CSDN that introduced that the rendering performance of FlashPlayer is several times that of HTML 5. Recalling the research on Adobe’s FlashPlayer over the past few years, I wanted to theoretically explore why there is such a result, and also explain Let’s talk about the reasons why Adobe’s Flash Player has been criticized for traditional hardware acceleration (non-GPU solutions);
In the early years, I worked in an IC design company to develop official Flash Player hardware acceleration for a low-end platform (with hardware 3D acceleration). Several At the end of the month, the hardware rendering engine was ready, but the final result was very unexpected - the performance after switching to hardware acceleration was actually worse than software rendering; in order to explain the reason, let's start with Adobe's Flash Player software Let’s start with the principle of rendering algorithm;
In fact, FlashPlayer’s 2D rendering engine uses the most common scan line algorithm (Scanline algorithm), and simply speaking, it is a virtual display device (for anti-aliasing considerations, the virtual display The device is larger than the actual display device, such as 4 x 4 anti-aliasing. The vertical length of the virtual display device is 4 times that of the actual display device.) Each scan line calculates the intersection point with each edge (Edge) of the vector graphic and fills it according to different filling rules. The horizontal line between the two intersection points; in this way, after the scanning lines are calculated one by one from top to bottom, a complete graphic is completed in the virtual display device. Then, according to the supersampling algorithm, the graphics on the virtual display device are The graphics are output to the actual display device, so that a perfect non-aliased graphic is obtained on the actual display device; the above actions are repeated at a certain rate, and continuous animation can be obtained; FlashPlayer parses the streaming swf file, And update the screen at the specified speed to complete the animation playback. Therefore, we have some simple conclusions:
l Vector operation is a huge calculation; this also explains why FlashPlayer has performance problems on most platforms; very regrettable Yes, the current real-time 2D vector graphics playback software seems to only have FlashPlayer, so there is no way to blame this scapegoat;
l Why is the display performance of high-definition graphics much worse than that of lower quality graphics? Because in high-definition settings, FlashPlayer uses 4 x 4 super-sampling anti-aliasing, and means that the calculation amount of calculating intersection points through scan lines is 4 times that of low image quality;
(For 2D vector graphics display, refer to my previous resources: http://download.csdn. net/source/5773340)
In actual 2D vector engines, the problem is often more complicated. After considering Cap and Join, in fact, even a very simple polyline or Bezier curve is composed of many curves (such as The two endpoints of the graph polyline----Cap):

This way we can understand why there are few real-time 2D vector display programs that can compete with Adobe FlashPlayer. Isn’t this a bit contradictory: Why does Adobe’s FlashPlayer stand out? ? The above is just a principle explanation of 2D vector graphics display. Other 2D vector display engines, such as OpenVG (gingkoVG), agg, etc., use the exact same principle. Adobe's FlashPlayer, a relatively common 2D vector display engine, must have its own special Definition, carefully read Adobe's official technical document about FlashPlayer (swf_file_format_spec_v10), we quickly found two very interesting instructions:
l FlashPlayer only supports 2nd order Bezier curve (Quadratic Bezier), and does not support similar PostScript and The third-order Bezier curve (Cubic Bezier) used in traditional 2D vector engines such as OpenVG;


Compared to the second-order Beizer curve, the amount of calculation added by a single third-order Bezier curve in calculating the intersection does not seem to be large: There are several more multiplication operations; however, in most CPU systems, multiplication and division operations take longer than addition and subtraction, especially when the amount of operations is very large, the cumulative difference is even greater;
l In Adobe's official website It is clearly stated in the file that FlashPlayer does not support dot-dash (Dash)


Why doesn’t it support Dash? In fact, in vector graphics display, in addition to the calculation of the intersection of the curve and the scan line, the most difficult thing is to calculate the length of the curve. The display of Dash must rely on the calculation of the curve length in advance; when implementing gingkoVG, the curve of the Dash function is not included It shows that its display performance is 4 times that of using Dash;
l Is that all? No, but even with the above constraints, its display performance has been "improved" several times. In Adobe's FlashPlayer, some other optimization algorithms are used for rendering. Of course, these optimization algorithms are also used in most 2D vector engines as general optimization techniques; (Reference: http://download.csdn.net/source /1998019)
It is a pity that most 2D vector engines support third-order Bezier curves, dot-dash lines, and even arcs (OpenVG) because of the need to consider versatility. From an algorithmic level, it is not difficult to understand why those The open source FlashPlayer that uses a standard 2D rendering engine (such as gnash uses agg) cannot be compared with the execution performance of Adobe's FlashPlayer ----- because the 2D rendering engine of FlashPlayer is tailor-made for the real-time needs of Flash playback ; Of course, in addition to these, Adobe's Flash Player has many clever features in program optimization, which are not what we need to discuss here;
It seems that the matter can come to an end here, but with in-depth research on Flash Player, we discovered some deeper problems ----- and the reasons for the poor hardware acceleration performance of Adobe's Flash Player that has been widely criticized; without considering the For the hardware acceleration of special GPUs, we only consider the standard hardware acceleration method (OpenGL ES/OpenVG) to explain this problem; when Adobe's FlashPlayer was born, there was no universal 2D vector display standard (such as OpenVG), which was aimed at software rendering. The 2D vector graphics display can be said to be a highlight. After more than ten years of development and optimization, Adobe's 2D software vector rendering engine has been developed to perfection. This can also explain why its rendering engine has not been improved from FlashPlayer 4 to FlashPlayer 8. Such a big change can also explain why Adobe FlashPlayer software rendering performance is even better than using low-end hardware acceleration; however, success is also a failure, and too perfect standards and algorithms hinder the use of standard hardware acceleration. Possibly (hardware acceleration for special GPUs, because its flexibility is not in our consideration), we continued to carefully study Adobe's official documents, and we noticed that FlashPlayer is different from traditional 2D vector engines regarding the filling law: traditional 2D vector engines (such as OpenVG/gingkoVG) have two fill rules: even-odd fill rule (Even-odd fill rule) and non-zero fill rule (Non-zero fill rule), and Adobe's FlashPlayer adds an edge fill rule ( Edge-edge fill rule), and most 2D vector engines use a single coloring method (RColor) for each Shape/Object. In the edge-edge fill rule, an edge can have two different coloring methods depending on the left and right ( color1/color2), of course the reason why Adobe does this is to increase the flexibility of software rendering. For example, when two Shapes intersect, different coloring methods are allowed for the intersecting parts, as shown in the figure:


Unfortunately, this is when using the standard Graphics acceleration engines (OpenVG/OpenGL) will bring us confusion: that is, we may have different shading methods for a Shape, which seems to be contrary to most 2D vector engines; although we can regard the edge filling rule as There are two different odd and even filling rules, but considering that the filling rules for each edge may change at any time, the reconfirmation of a Shape with a single Color is not that easy, especially for a Shape composed of curves. However, this problem is not very troublesome compared to 2D vector graphics rendering, but we can find that Adobe FlashPlayer does not seem to be "friendly" to most traditional 2D vector engines today ----- Programmers must carefully write an intermediate layer to solve these problems , this is not Adobe's fault: these 2D vector display standards (OpenVG) had not yet appeared when FlashPlayer was born; it is just a pity that Adobe's FlashPlayer is not an open source program (AVM2 of Adobe FlashPlayer has been open source), so we must wait patiently Adobe does this for us, unless we are not going to use the official FlashPlayer;
(We use OpenVG’s FlashPlayer ourselves)