My point is that the content isn't identical unless your WebGL backend is emulating all the steps that Canvas implementations are required to take in order to conform to the specification. I do agree that it shouldn't matter as long as the output looks the same, but that's clearly not the case either as you demonstrate by the screenshots showing how much better your WebGL version looks.
I simply think it's a misleading comparison. You could easily compare Canvas performance in Firefox and Chrome against Canvas performance in IE and the better browsers would probably still come out ahead. If you wish to simply demonstrate that WebGL is faster than Canvas, you should do that comparison in the same browser. You could also demonstrate some of the use cases that simply aren't possible with Canvas, or are much slower (blend operations, for example).
My perspective comes from porting a bunch of XNA games to HTML5, so I've spent a lot of time digging into the semantics of Canvas and trying to figure out how to use it to achieve precise results in varied scenarios. That's part of why I think it's inaccurate to treat it as equivalent to just drawing textured quads with WebGL. A lot goes on under the hood.
But the fact WebGL doesn't have to do everything a standards-compliant Canvas has to is the whole point! That's exactly why it's a faster way to draw, and the results are quantifying that. IE doesn't support a new API to draw faster; we highlight this with the performance measurements. I still think this is a totally fair thing to do. Even just how much faster is an interesting point: Chrome measures 25x faster in one test, and that's Javascript going up against the native code in IE's engine that presumably issues Direct3D calls to draw the canvas. You could easily assume Javascript would have been slower. I think overall it's both an interesting and valid point to make.
For the record - the different rendering with WebGL was a separate point about supporting shaders, the performance measurements were all based around identical-rendering tests.
I simply think it's a misleading comparison. You could easily compare Canvas performance in Firefox and Chrome against Canvas performance in IE and the better browsers would probably still come out ahead. If you wish to simply demonstrate that WebGL is faster than Canvas, you should do that comparison in the same browser. You could also demonstrate some of the use cases that simply aren't possible with Canvas, or are much slower (blend operations, for example).
My perspective comes from porting a bunch of XNA games to HTML5, so I've spent a lot of time digging into the semantics of Canvas and trying to figure out how to use it to achieve precise results in varied scenarios. That's part of why I think it's inaccurate to treat it as equivalent to just drawing textured quads with WebGL. A lot goes on under the hood.