5 ms·

Web Audio API on iOS 6 is pretty cool, because <audio> on iOS is so limited it's pretty much impossible to use for games... and the Web Audio API works great, e

Web Audio API on iOS 6 is pretty cool, because <audio> on iOS is so limited it's pretty much impossible to use for games... and the Web Audio API works great, even with polyphonic audio! So it's an actual valuable improvement. AFAIK both Web Audio and WebGL are planned for Chrome on Android, but I can't explain the delay - it's still stuck on version 18 there, while desktop is 23. Can't speak for Google's plans there but I'm pretty sure they will eventually do it. I think our perspectives differ because my view is different to yours: we develop a large, does-everything HTML5 game engine, and I suppose you're arguing more from the point of an independent developer hand-coding a game. So I can see where you are coming from, but I still disagree about WebGL. Our engine doesn't care about how anything as drawn, as long as it looks right. Both WebGL and Canvas 2D achieve that goal, and one happens to be faster. Since we don't need two identical interfaces and can happily maintain two renderers, this is a win for us. In fact, WebGL can render absolutely everything Canvas 2D can, just with a different (and still standard) API. I think it's fair to compare the performance of two different APIs, especially when they are drawing identical content.

kevingadd 14y ago
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.
- AshleysBrain 14y ago
  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.

kevingadd 14y ago

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.

AshleysBrain 14y ago
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.