Google Docs announced that it will migrate HTML to rendering based on Canvas. The emergence of this news has once again pushed the tags that were born with HTML5 a few years ago to people's attention. The main advantage of Canvas when it was first launched was faster rendering speed, which can be called the "Su Bingtian" of HTML, refreshing people's impression of the speed of Web page element drawing. But are the advantages of Canvas limited to this?
(Su Bingtian, the first person in 100 meters in Asia)
The predecessor of HTML graphics: SVG
Canvas is a "new" tag introduced in the HTML5 era. Unlike many tags, Canvas does not have its own behavior. It only exposes a set of APIs to client-side JavaScript, allowing developers to use scripts to draw what they want to draw onto a canvas.
Before HTML5, people usually used SVG to draw graphics on the page. SVG uses XML to define graphics, just like using HTML tags and styles to define DIVs, we can also imagine a blank DIV as a rectangular SVG. The design ideas of the two are the same. The essence of SVG is a DOM element. But Canvas is different. Canvas provides JavaScript drawing API instead of using XML to describe drawing like SVG. Drawing directly through JavaScript API is easier and more direct than modifying XML.
In addition to the way of definition, the difference between Canvas and DOM (and of course SVG) is more reflected in the way the browser renders.
When the browser is rendering the page, the Dom element is rendered as a vector diagram. The margins of each element need to be processed separately, and the browser needs to process them all into pixels before they can be output on the screen, which requires a huge amount of calculation. When there is a lot of content on the page and there are a lot of DOM elements, the rendering speed of these content will become very slow.
(Canvas)
The difference between Canvas and DOM is that Canvas is essentially a bitmap, similar to an img tag, or a div with a background-image. Therefore, the problem of DOM-like vector rendering in rendering is completely different when it is replaced with Canvas. When rendering the Canvas, the browser only needs to execute the drawing logic in the JavaScript engine, build the canvas in memory, and then traverse the colors of all pixels in the entire canvas, and output directly to the screen. Regardless of the number of elements in the Canvas, the browser only needs to process one canvas during the rendering phase.
However, this more powerful function inevitably makes the use of canvas rendering have a high threshold. In the process of building Canvas, Google Docs redefines what people are familiar with, such as precise positioning, text selection, spell checking, redrawing and tuning. Why do more developers choose to adopt Canvas, a technical route with a higher threshold? This brings us back to the biggest advantage of Canvas: rendering performance.
Canvas rendering mode
The rendering here refers to the process by which the browser renders the code of the page as content on the screen. The rendering modes of Canvas and Dom are completely different, and it is important to understand the performance advantages of Canvas to understand this difference.
Dom: Resident mode
Retained Mode is the rendering mode of Dom in the browser. The following figure roughly shows the workflow of this process.
(Residence mode)
The core of DOM is tags, a text markup language with strong diversity and various associations between multiple tags (such as sub-DIVs set to float under the same DIV). In order to better handle these DOM elements and reduce the calls to the drawing API, the browser has designed a set of "resident mode" that stores intermediate results in memory. First, the browser will parse all DOM-related content (including HTML tags, styles and JavaScript), convert them into scenes and models and store them in memory, and then call the system's drawing API (such as Windows Programmers are familiar with GDI/GDI+) and draw these intermediate products to the screen.
The resident mode reduces the frequency of calling the drawing API through the scene and model cache, and transfers the performance pressure to the scene and model generation stage. That is, the browser needs to "judge by itself" the size of each element based on the DOM context and the size data in the BOM. Draw the result.
Canvas: Quick mode
Canvas uses Immediate Mode, which is different from DOM. Let's first take a look at how the Immediate Mode works:
(Quick mode)
Application advantages of Canvas
The two different modes introduced above directly cause the performance difference between Dom and Canvas. For Canvas rendered in fast mode, every redraw of the browser is based on code. There is no multi-layer analysis that slows down the processing flow, so it is really fast. In addition to being fast, Canvas's flexibility greatly exceeds DOM. We can precisely control how and when to draw the effect we want through the code.
In terms of resource consumption, the DOM resident mode means that every additional thing in the scene requires additional memory consumption, and Canvas does not have this problem. This difference will become more obvious as the number of page elements increases. Take the enterprise application scenario on the B side as an example. In the scenario where the data volume of the form is relatively small, the effect of different rendering modes is not obvious; but in the scene of the operation of Excel spreadsheets such as industrial manufacturing, financial accounting, etc., the cell The number is easily millions (50,000 rows x 20 columns) or even hundreds of millions. The browser needs to render the contents of all the cells in the table, and it also involves rich data processing. The situation is completely different.
(The spreadsheet on the Web page contains 1 million cells)
Before the advent of Canvas, rendering tables on the front end could only be achieved by constructing a complex DOM. In this way, the performance of the browser has become the bottleneck of Web applications, causing many developers to give up the idea of implementing spreadsheets on the browser.
After the emergence of Canvas, the performance advantage brought by the fast mode is undoubtedly a huge bright spot, and the performance problems brought by the massive and complex DOM rendering processing finally have a solution.
back to the application scenario of spreadsheets, the 16125c0580cdd6 table component that uses Canvas to draw the canvas has appeared in the industry. This type of component not only does not need to repeatedly create and destroy DOM elements when rendering the data layer, but it is also better than the Dom element in the canvas drawing process. There are fewer restrictions on rendering. In addition to tables, Canvas has also brought changes to scenes such as digital twin visualization large screens and page games.
(Digital twin large screen, precise control of various shapes and styles)
Summarize
To sum up, in the rendering mode, Canvas stands on the opposite side of the DOM. The browser knows nothing about its content. All rendering rights are returned to the developer. This change brings significant performance advantages. In addition, we can use Canvas to draw a richer variety of UI elements, such as line shapes, special graphics, etc. Through the drawing logic, we can also achieve more accurate UI interface rendering, which solves the style error caused by browser differences and allows more Application scenarios can be smoothly migrated to the Web platform.
Reference materials:
· based on Canvas form component SpreadJS
Please indicate the source for reprinting: Grape City official website , Grape City provides developers with professional development tools, solutions and services, and empowers developers.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。