Google Docs has announced that it will move HTML to Canvas based rendering, putting tags back on the map that came with HTML5 a few years ago. At the beginning of its launch, Canvas’s main advantage is faster rendering speed, which can be called “Su Bingtian” of HTML. It has refreshed people’s impression on the drawing speed of Web page elements. But does Canvas’s advantage end there?
The predecessor of HTML drawing: SVG
Canvas is the “new” tag introduced in the HTML5 era. Unlike many tags, Canvas doesn’t have its own behavior. It just presents a set of apis to the client JavaScript, allowing developers to use scripts to draw what they want onto a Canvas.
Before HTML5, SVG was commonly used to draw graphics on pages. SVG uses XML to define graphics, just as IT uses HTML tags and styles to define divs, we can think of a blank DIV as a rectangular SVG. The design philosophy is the same. SVG is essentially a DOM element. Canvas, on the other hand, provides the drawing API of JavaScript instead of using XML to describe drawing like SVG. It is easier and more direct to draw directly through JavaScript API than to modify XML.
Apart from the definition, the difference between Canvas and DOM (and of course SVG) is more reflected in the way browsers render.
When browsers render pages, Dom elements are rendered as vectors. The margins for each element need to be handled individually, and the browser needs to process them all into pixels before it can be printed on the screen, which is a lot of computing. When there is a lot of content on the page and there are a lot of DOM elements, the rendering of that content is slow.
(Canvas)
The difference between Canvas and DOM is that Canvas is essentially a bitmap, similar to IMG tag, or a div with a background-image. So the DOM vector rendering problem is completely different on Canvas. When rendering a Canvas, the browser only needs to perform the drawing logic in the JavaScript engine to build the Canvas in memory, and then iterate over the colors of all pixels in the entire Canvas and output them directly to the screen. No matter how many elements there are in the Canvas, the browser only needs to process one Canvas during the rendering phase.
However, such more powerful functions inevitably make it difficult to use Canvas rendering. Google Docs redefines the familiar things like precise positioning, text selection, spell checking, redrawing, etc., in the process of building Canvas. Why do more developers choose to embrace Canvas, a technology with a higher threshold? This brings us back to Canvas’s biggest advantage: rendering performance.
Canvas rendering mode
Rendering here refers to the process by which the browser renders the code for a page as what’s on the screen. Canvas and Dom have completely different rendering modes, and understanding this difference is crucial to understanding Canvas’s performance advantages.
Dom: resident mode
Retained Mode is the Dom rendering Mode across the browser. The figure below shows a rough workflow for this process.
(Resident mode)
At the heart of DOM is the tag, a text markup language with a lot of diversity and associations between multiple tags (such as child divs set to float under the same DIV). To better handle these DOM elements and reduce calls to the drawing API, browsers have designed a “resident mode” that stores intermediate results in memory. First, the browser parses all content related to the DOM (including HTML tags, styles and JavaScript), converts it into scenes and models and stores them in memory, and then calls the system’s rendering API (such as GDI/GDI+, familiar to Windows programmers). Draw these intermediates onto the screen.
Resident mode reduces the frequency of calls to the drawing API through the scene and model caches, shifting the performance pressure to the scene and model generation phase, where the browser needs to “judge” the drawing result of each element based on the DOM context and the dimensional data in the BOM.
Canvas: Fast mode
Canvas uses a different Immediate Mode than DOM. Let’s see how the Immediate Mode works:
(Quick Mode)
Advantages of Canvas application
The two different modes described above directly contribute to the performance difference between Dom and Canvas. For a Canvas rendered in fast mode, every redraw of the browser is code based and there are no layers of parsing that slow down the process, so it’s really fast. In addition to being fast, Canvas is far more flexible than DOM. We can use our code to control exactly how and when we want it to look.
In terms of resource consumption, DOM’s resident mode means that every addition to the scene requires additional memory consumption, whereas Canvas doesn’t have this problem. This difference becomes more pronounced as the number of page elements increases. Take the b-side enterprise application scenario as an example. For a form with a relatively small amount of data, different rendering modes have no obvious effect difference. However, in the case of industrial manufacturing, financial accounting and other Excel spreadsheet operations, where the number of cells can be in the millions (50,000 rows x 20 columns) or even hundreds of millions, the browser needs to render the contents of all the cells of the table itself, and rich data processing is involved, the situation is completely different.
(Spreadsheet on Web page, 1 million cells)
Before Canvas, rendering tables in the front end could only be done by building complex DOM. In this way, the performance of the browser becomes a bottleneck for Web applications, leading many developers to abandon the idea of implementing spreadsheets in the browser.
After the emergence of Canvas, the performance advantage brought by fast mode is undoubtedly a huge bright spot, and the performance problem brought by a large number of complicated DOM rendering processing finally has a solution.
Going back to the spreadsheet scenario, there are already table components that use Canvas to draw a Canvas. Not only do these components render data layers without having to repeatedly create and destroy DOM elements, but they are also less restrictive in the Canvas rendering process than DOM elements. In addition to tables, Canvas also brings changes to the digital twin visualization of large screens, page games and other scenes.
(Digital twin large screen, precise control of various shapes and styles)
conclusion
To sum up, the Canvas stands on the opposite side of the DOM in rendering mode, the browser knows nothing about it, and all rendering power is back in the hands of the developer, which brings significant performance benefits. In addition, we can use Canvas to draw a richer variety of UI elements, such as lines and special graphics, etc. Through drawing logic, we can also achieve more accurate UI interface rendering, solve the style error caused by browser differences, so that more application scenes can be smoothly transferred to the Web platform.
References:
· Canvas Wiki introduction
Canvas community,
· Based on Canvas table component SpreadJS
The official website of Grape City, grape city for developers to provide professional development tools, solutions and services, enabling developers.