If you've done much work with the HTML5 canvas API, and especially if you've ever looked into performance tuning your canvas apps, you've likely come across the advice to batch your canvas calls together. For example, you may have read that when drawing multiple lines or shapes, it's better to create a single path and only call your draw method once, drawing all lines and shapes in one go, than it is to draw each line or shape individually. In other words, this:
1 ctx.beginPath();
2 lineArray.forEach(function(line){
3 ctx.moveTo(line.startx, line.starty);
4 ctx.lineTo(line.endx, line.endy);
5 });
6 // Draw all lines at once.
7 ctx.stroke();
8 ctx.closePath();
is preferable to this:
1 lineArray.forEach(function(line){
2 ctx.beginPath();
3 ctx.moveTo(line.startx, line.starty);
4 ctx.lineTo(line.endx, line.endy);
5 // Draw each line individually.
6 ctx.stroke();
7 ctx.closePath();
8 });
As I recently discovered, however, this does not always hold true. Performance in certain browsers actually degrades very quickly as the number of subpaths increases above a certain threshold. More information about how different browsers perform can be found at this jsperf.
The following test method was used in order to obtain quantitative data to investigate this issue:
1 <!DOCTYPE html>
2 <html lang="en">
3 <head>
4 <meta charset="UTF-8">
5 <title>Long Path</title>
6 </head>
7 <body>
8 <canvas id="canvas" width="600" height="600"></canvas>
9 <script>
10 (function(){
11 var canvas = document.getElementById('canvas');
12 var ctx = canvas.getContext('2d');
13 ctx.strokeStyle = "red";
14
15 var results = [];
16
17 // Draw increasingly long paths
18 for (var i=0; i<2000; i+=20){
19 ctx.clearRect(0,0,600,600);
20 var start = performance.now();
21 ctx.beginPath();
22 for (var j=0; j<i; j++){
23 ctx.moveTo(0, j);
24 ctx.lineTo(j, 0);
25 }
26 ctx.stroke();
27 ctx.closePath();
28 var end = performance.now();
29 results.push(end-start);
30 }
31 })();
32 </script>
33 </body>
34 </html>
What this code is doing is drawing paths to the canvas with increasingly many subpaths. performance.now() was used to
measure execution time, as it provides higher resolution timestamps than Date.now(). Results were stored in an array,
which was used to produce the chart below.
The takeaway, it would seem, is that you may see performance drop off precipitously in some browsers when the number of subpaths in your path reaches or exceeds ~600. If you encounter this issue, in order to work around it, paths should be periodically drawn and closed. In other words, paths should not be fully batched together, but should be batched into chunks. Experimentation has shown that keeping subpaths to <200 provides relatively good performance.
Addendum: Further testing suggests this issue is not very widespread at all, and does not affect all versions of Firefox. Currently, these results are reproducible in Firefox 31.0 running on Arch Linux. Firefox 31.0 running on OS X 10.7 does not produce similar results. After further investigation, this sounds like it may be an issue with cairo.