Rendering an interface through Canvas

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



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

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

Complexity of use

As the test development showed, the solution to canvas is definitely more complicated and requires careful organization of the code so that in the future it is easy to change the appearance of the plate, in this regard, css is much more convenient.
There are also a number of non-obvious points - when rendering through the canvas, the browser tries to smooth out all the lines, and you have to use a not the most standard approach - in particular, the entire plate is drawn with fill (not fill) and not with lines.

Render speed

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

Chrome 9

Rendering (smaller is better)

Changing data (smaller is better)


Although the canvas is much worse than the canvas (the scale is logarithmic, so the gap is really big), in the scenario with changing the data, canvas shows the best results. Moreover, the rate of change in the case of canvas does not depend on the total data size - it is almost constant for all tests.

The difference between the tests of the "large table" and the "large table with styles" is also indicative. The complexity of the appearance has little effect on the canvas solution, but it slows down the HTML solution somewhat. Most likely, with further complication of styles, the gap between HTML and Canvas rendering will narrow.

Opera 11

Rendering (less is better)

Changing data (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 table but could not draw a larger canvas, so they did not get their charts.

• Firefox 4b10
• IE9
• GPU accelerated Chrome

Comparison of different browsers

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

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

The feeling of using

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

Results as i see them

No miracle happened. Although canvas shows very good results, the speed of rendering similar interfaces via html is still higher.
However, at the same time, to draw a complex interface in which some small elements are constantly changing, canvas can be preferable due to a very high update speed (which does not require recounting and redrawing of all related DOM elements)

As Opera has always stood out, this is the only one a browser in which drawing with canvas can be really faster than doing the same through HTML.

Browsers supporting hardware graphics acceleration were unpleasantly surprised - they all refused to work with a canvas that exceeded the screen size. I would like to believe that this is temporary and will be fixed in the next / final versions.