IE10 review: still disappointing for HTML5 games | Hacker News Reader

IE10 review: still disappointing for HTML5 games

scirra.com

54 pointsAshleysBrain38 comments

This benchmark is a bit misleading, as it is not comparing like with like.

On the only benchmark where WebGL doesn't help, IE 10 does respectably. I have found in my limited testing of 2d canvas that IE 10 performs quite well.

While it would be nice to see WebGL in IE10, 2d canvas-based apps perform very well.

Until recently I recall seeing some canvas apps performing much smoother in IE9/IE10 than in Chrome.

I agree with respect to games Chrome and Firefox are pulling ahead, but with respect to publishing IE10 is ahead. Things like grid layout, positioned floats, and regions are awesome to more easily make good looking websites. While I do enjoy games, I would rather Chrome and Firefox work on adopting these new css primitives more than working on OpenGL and audio APIs.

Is anyone really THAT surprised, though? I feel like indie game developers who are using HTML5 techniques still mainly target modern browsers (Chrome, Safari, and Firefox). There might have been a hope of say "it will be awesome if everything starts to work on IE", but I highly doubt those developers were dying for IE. Plus, if you look at the majority target market for HTML5 gamers, those users will most likely be using modern browsers anyways.

I thought IE10 was a "modern browser"?

Not according to this: http://html5test.com/results/desktop.html. BUT, IE will start to auto update their browsers here sometime soon, and in my books that's what makes a browser modern right now.

The score for IE10 is 320. It's close to Safari 5.1, the previous version of Safari, which scores 319.

Of course, it's not as high as the current leader (Maxthon 3.4.5 at 457), but IE10's got a decent score, and is definitely a big improvement compared to IE9.

Or at last, it was supposed to be...

You are right, that was a poor usage of the phrase "modern browser", but I'm sure you know what I meant (Chrome, Safari, and Firefox).

It is. It's just one step behind, and that's one step too far for some people.

I'm not sure how you're categorizing "modern browsers", but this is disappointing for any developers who hope to reach audiences on Windows RT or Windows Phone 8 without needing to make an app for those platforms.

As mentioned below in another comment reply I made, that was a poor usage of "modern browsers". I meant like Chrome, Safari, and Firefox. Also, I agree that it's disappointing, but I also don't think it's necessarily a "deal breaker" for the features that IE10 is missing. However, that will depend on the style of HTML5 game that you are building.

It's currently easier to get a HTML5 game working in IE10 than it is in Windows Safari, for what it's worth. But I think I agree with your premise that HTML5 game developers aren't really targeting Internet Explorer in general. People who care about users on IE seem to be sticking with Flash.

I don't really see the point of comparing IE10 (just released) to a browser that has a minuscule browser share and hasn't been actively developed or updated in something like 6 months.

You can compare a preview build of IE10 from 6 months ago with a Windows Safari nightly from today and IE10 will still win. I have.

Disappointing, perhaps, but somehow it still manages to be better than Opera and Safari (Windows Safari, at least) for HTML5 games based on my testing [1]. Going from last place to third place in such a short time period is an achievement in my book, even if I'd still never use IE as my primary browser.

Admittedly IE10 is still missing some features I would mark as important for game development, but when I contacted some IE devs over at Microsoft (just send an email!) they got back to me with simple workarounds that made it possible to get my games running with a few lines of additional code. (Not IE-specific code either, just clever feature-detection fallback for any browser.)

Here's how I suggest looking at it instead: Holy shit, the browser that comes stock on Windows 8 can actually run a large majority of HTML5 games and applications! You don't have to nag people to install Chrome or Firefox just to use your app! Sure, you want them to upgrade anyway - and they probably will - but that's something!

Now if IE11 comes out and doesn't advance the state of things here I'll certainly be disappointed, but at present I'd say I'm actually quite pleased: in the jump from 9 to 10 MS has brought IE forward enough that you can run HTML5 games in it without having to write a ton of browser-specific hacks or feature implementations.

WebGL support would be nice, but you still can't rely on WebGL in HTML5 games anyway since it doesn't work on a large percentage of desktop machines and is basically unusable on mobile. I think this is another area where the pressure should be on MS to get a rock solid implementation of WebGL into IE11, not to complain about IE10 not having an API that is arguably still not ready for prime time (Though increasingly close).

Complaints about not having the Web Audio API are similarly missing the point since you can't use it anyway unless you're writing a Chrome Experiment - your real complaints should be reserved for the fact that IE still has an undocumented limit on the number of live <audio> instances you can put in a single page, or for IE's latency when playing new sound effects.

Finally, allow me to repeat others' comments that it's incredibly stupid to benchmark a canvas-based game against a webgl one and present the numbers side-by-side with a straight face. Canvas performance is miserable in every single browser and IE has nothing to do with this. IE actually has one of the better Canvas implementations out there. The fault lies with Canvas being a poorly-specified, poorly implemented API, not with IE.

[1] I regularly test all my HTML5 game ports across the major browsers and regularly hit crash bugs in Safari and Opera. Also, Windows Safari still can't play back audio which is... inexplicably stupid.

Is Windows Safari still actually developed at all?

Nope, it was silently killed.

Hmm, seems pretty irresponsible of Apple to do that, given that it's thus going to go unpatched and its users will become progressively more vulnerable, no?

Apple doesn't really seem to care much about responsibility or security.

This is good to know. I had assumed up until this point that it was merely behind the curve (I've been using WebKit nightlies since they're labelled as Safari...)

Seems as dead as Snow Leopard's: latest version is 5.1.7 (webkit 534.57.2); current version is 6.0.2 (webkit 536.26).

For comparison, Chrome 12 used webkit 534.30, Chrome 20 used webkit 536.10, Chrome 23 uses 537.10.

>somehow it still manages to be better than Opera and Safari (Windows Safari, at least) for HTML5 games based on my testing

Same here. I still note that IE9 and IE10 run some things a lot smoother than Chrome.

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.

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.

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.

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 don’t think Opera and Windows Safari matter even a little bit.

Chrome, Firefox and Safari (not so much the OS X version, rather the mobile version). That’s the benchmark.

Why is it stupid to compare the performance difference between canvas and WebGL? From where I'm standing a developer would have to make a choice between using that extremely poor performance to create a very crappy game, or it can use WebGL to create something that is a bit more presentable.

If a developer has to choose between these 2, which one do you think he will choose?

Though the comparison HAS to be between 2d canvas and WebGL due to IE not implementing the latter, it does feel a tad unfair. Maybe someone with more knowledge could chime in about what optimizations are possible 3D that aren't possible on a 2D canvas.

It would also be interesting to see how FF and Chrome performed on the same 2D canvas test.

It's possible to achieve a factor of 10 (perhaps even 100) better performance for typical 2D workloads by using WebGL instead of Canvas. This is a mix of the Canvas API specifying that things have to be rendered in a relatively expensive fashion, and the actual Canvas implementations not being particularly performant (despite some really impressive efforts in that area by the browser vendors).

WebGL is not supported in IE because of some important reasons, it's just not secure enough.. yet.

Most succesful games are not using it anyways.

  Recently Chrome and Firefox also added an experimental
  feature currently being standardised to also allow point
  sampling in their Canvas 2D renderer

Anybody have a source or reference for this?

I was referring to the new Canvas 2D context 'imageSmoothingEnabled' property: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

As with Vorbis, the lack of WebGL is political as its based on OpenGL which is a threat to DirectX.

Theres some hope for Opus as Microsoft's Skype division is pushing it (its partly based on Skype tech)

Can developers use IEWebGL as a fallback for IE users?

how can be a markup language disappointing? The Interpreter in this case IE10 can only be disappointing...

Reply on news.ycombinator.com