Rendering the interface via Canvas

One of the very tasty features of HTML5 is Canvas support, the canvas on which you can draw arbitrary content. In most cases I know, it is used for animations, games, and small visual decorations. There are practically no cases when using it the application interfaces are rendered (I only know Bespin from Mozilla Labs) - to find out if this is a crazy idea or the time for new solutions, I spent Sunday evening on a number of experiments.


')
First you need to clearly limit the intended scope of use - talking about web applications with a complex interface not intended for mass services (typical business applications are their darkness). For this type of application, the content indexability is not important to us (which is zero in the case of canvas) and we may not care about the support of the entire browser zoo (it is enough that everything will work well in at least one browser).

For the tests, the most frequently used element was chosen - a data plate (500,000-row labels or 200 columns - this is the harsh reality of business applications). All test pages can be found here .
From personal experience - the most critical parameter is the speed of rendering large amounts of data - here we will see if the canvas can help us. Of course, with a good design, the screen should not have these very large amounts of data, but in practice the requirements of the customers differ from the ideal.

Difficulty of use

As the test development has shown, the solution for canvas is definitely more difficult and requires careful organization of the code so that in the future it is easy to change the appearance of the tablet, in this respect css is much more convenient.
There are also a number of unobvious moments - when drawing through the canvas, the browser tries to smooth out all the lines, and you have to use a non-standard approach - in particular, the entire label is drawn with fillings (fill) and not with lines.

Drawing speed

Two parameters were measured
- table rendering speed
- the rate of change of a single cell in the table already drawn

Chrome 9

Drawing (less is better)

Data change (less is better)


Although the canvas is significantly losing for drawing (the logrifmic scale, so the gap is really large), in the scenario with data changes, the canvas shows the best results. Moreover, the rate of change in the case of canvas does not depend on the total size of the data - it is almost constant for all tests.

The difference between the “big table” and “big table with styles” tests is also indicative. Complicating the appearance has little effect on the canvas solution, but somewhat slows down the HTML solution. Most likely, with further complication of styles, the gap between HTML and Canvas rendering will be reduced.

Opera 11

Drawing (less is better)

Data change (less is better)


The opera is sad with large HTML tables, they are rendered just insanely long.

Other

The following browsers coped with the small and medium tables but could not draw a larger canvas, so they were not honored with their charts.

• Firefox 4b10
• IE9
• Chrome with GPU acceleration enabled

Comparison of different browsers

Test for the average table in all browsers (less is better)

In general, everything is predictable - Chrome and FF in the lead. A somewhat unexpected result is the inclusion of GPU acceleration in Chrome (Chrome * in the diagram)

Sensations of use

Starting from medium size and higher - tables rendered via HTML noticeably slow down when scrolling (most likely the browser does not draw them immediately, but on the fly, which causes jerks during scrolling), the canvas scrolls smoothly and without any jerks.

Results as i see them

The miracle did not happen. Although the canvas shows quite good results, the speed of rendering similar interfaces via html is still higher.
However, at the same time, for rendering a complex interface in which some small elements are constantly changing - the canvas may be preferable due to the very high update rate (which does not require recalculation and redrawing of all associated DOM elements)

As always, Opera has stood out - it is the only browser in which drawing can be really faster than doing the same through HTML.

Unpleasantly surprised browsers supporting graphics acceleration - they all refused to work with the canvas that exceeds the screen size. I would like to believe that this is temporary and will be fixed in the next / final versions.