2 ms·

Author here. I think Safari gets bonus points for being easily the best mobile browser for HTML5 games, and Opera are actively working on WebGL support. Also,

Author here. I think Safari gets bonus points for being easily the best mobile browser for HTML5 games, and Opera are actively working on WebGL support. Also, the Web Audio API is available to all web pages in all recent stable Chrome builds, as well as Safari on iOS 6+ - it's not just a Chrome experiment. The Web Audio API, along with WebGL, are both very good things for HTML5 games, and especially larger engines like ours. I think they're both ready for prime time and the fact other browser makers haven't got round to it isn't any excuse not to support it. Why can't IE be a browser that leads the way rather than leaving Chrome and Firefox to invent everything? Why is it stupid to put canvas 2D head-to-head with WebGL? They're both rendering the same thing, and it illustrates how WebGL is far faster than canvas 2D for drawing the same content. That's an important consideration for a HTML5 game engine, no? Under the hood most canvas 2D implementations plug in to a 3D API at the same level as WebGL, and it shows how cutting out the middle man can win you lots more FPS.

kevingadd 14y ago
I wasn't aware the Web Audio API had rolled out in iOS 6; that's pretty nice. I still consider it a toy, though, given that it literally works nowhere else - not even in Chrome on Android. Unless you are building for specific browsers, it is little more than an annoyance you have to put up with to get audio that works across all browsers (because <audio> STILL doesn't work right in WebKit browsers). Canvas and WebGL are fundamentally not the same thing. The Canvas API specifies a bunch of behaviors (some of them very expensive to implement) and it also specifies an API that is inherently inefficient and poorly suited to what most 2D games do. If you were to benchmark a WebGL implementation of the Canvas API (to spec) against Canvas, that would be realistic. You can do that, there are a couple out there - but you might find that they don't really perform much better. WebGL2D certainly doesn't; it's slower than Canvas in many cases.
- AshleysBrain 14y ago
  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

I wasn't aware the Web Audio API had rolled out in iOS 6; that's pretty nice. I still consider it a toy, though, given that it literally works nowhere else - not even in Chrome on Android. Unless you are building for specific browsers, it is little more than an annoyance you have to put up with to get audio that works across all browsers (because <audio> STILL doesn't work right in WebKit browsers). Canvas and WebGL are fundamentally not the same thing. The Canvas API specifies a bunch of behaviors (some of them very expensive to implement) and it also specifies an API that is inherently inefficient and poorly suited to what most 2D games do. If you were to benchmark a WebGL implementation of the Canvas API (to spec) against Canvas, that would be realistic. You can do that, there are a couple out there - but you might find that they don't really perform much better. WebGL2D certainly doesn't; it's slower than Canvas in many cases.

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