A Standard HTML5 Standard Standard

Posted by Vaughan on Mar 26, 2011 in Coding, HTML5 | 0 comments

After working on www.wayoutwars.com, and tinkering with other ideas since, my original thoughts on HTML5 increasing the gap between browsers is becoming apparent.  Having the HTML standard is awesome, but until everyone has a standard approach to the standard, we’ll still be making exceptions. 

Not everything in this post is HTML5, more HTML and JavaScript in general, but with HTML becoming an evolving standard it makes it more important for there to be consistency as adoption of HTML features will become increasingly staggered.

The core issue is with interpretation, and/or certification.  Who certifies that a browser is HTML* compliant?  Whether it’s a central body, or an individual tester, they need to ensure there is consistency, but in the scenario of the individual tester, what is the benchmark?  If text is being rendered on the page, what are the metric to measure that it is rendered correctly?   I’ll take a step back from HTML to explain. 

Bad Jump

If I was to write a specification for a computer game, one of the aspects to be described is controls.  To simplify it for discussions sake ”when a player hits ‘fire’, the character will jump.  Jump duration is a maximum of 2 seconds, to a height of 10 units”.  But how this occurs has many options: 

• Is there in air control?
• Is there hang time at peak or is it a parabolic jump?
• Does the character slow down in the air? 
• If the character hits a ceiling/wall do they fall immediately or still hang?
• …

New initiatives in games are benchmarked against all the previous successors.  There is always a parallel.  This is why jump times in all 2D platform games are about the same. 

Coming back to HTML, the standard may be open for interpretation, but just because a new standard is being implemented doesn’t mean that the function of the standard should behave any differently that you would normally expect. 

I’ll start with the basics.

Text Rendering

One of the fundamental things that every browser does and has done since the beginning, is render text.  Visually, this is the primary concern of the browser.  So one would expect that this is something that does not merit discussion. 

As such, I’m not sure how this gets through testing, but take a look at the following in Firefox and in parallel have a look in Chrome and IE9.

Chrome just AA’s the entire thing into a blurry mess, but at least it makes sense, if undesirable. IE9 realises it’s rendering text, and does more intelligent text smoothing.

But Firefox’s behaviour be described as a bug.  By default, text should be render with no anti aliasing, and if you have some smoothing it shouldn’t degrade the legibility of the text.  Having to design for another browser, or cater for it in code, is bad.  This just makes everyone design in to keep their designs predictable and maintainable. For those without HTML5, or Firefox, or super sonic zoom eyes, let’s have a closer look at FF’s rendering.

NOTE: You do not need 3D glasses to view the above picture.

Once your eyes stop bleeding, lets look at what is actually being rendered.  Anti aliasing with shades of red, green, and blue?  What is going on here isn’t in the style of Apple IIE monochrome monitors (for those that remember) but actual colours being rendered.  A single vertical line has a line of blue, a line of green, and a line of red.  Did anyone actually test this?  It’s like no one knew how to do text smoothing, so they just put 1 of each colour around the text.

Also notice how the vertical line in IE is doing anti aliasing on the 1 pixel line, making it appear transparent, and in Firefox it decides to make a 2 pixel wide line to avoid the issue altogether.  So while IE9 has good text smoothing, the anti aliasing logic in both browsers is broken and inconsistent.

It also negates the awesomeness of WOFF and the Google font API if you have to use bitmap font templates to have consistency (and even then not 100% reliably).

Media Handling

MP3 vs OGG.  I’ve stated my views on this.  Support OGG if you want, but don’t ignore MP3 if you want to be serious about creating a media rich web.  MP3 is out there, everywhere, and creating a barrier for innovation is dumb.

I won’t start on video codecs, that’s just too much of a mess for now.

Secondly, the extremely poor memory management regarding audio.  In all browsers, eventually media elements hit a limit.  For most sites this isn’t an issue.  But at about 50 megs of audio, IE9 stops loading new audio, even though the previous audio elements were removed.  They had to be ‘delete’ed.  Chrome hit this issue a few tracks later.

When deleted every browser behaves consistently and smoothly, except Chrome, which goes silent for no apparent reason at around 280 megs of audio.

You may ask why on earth would a page have 280 megs of audio?  This isn’t isolated to www.wayoutwars.com but is also a problem for audio stores where you can preview sample audio, and online radio such as www.lastfm.com that could be playing gigabytes of tracks.

JavaScript

I’m not talking syntax, but being able to crash a browser in JavaScript doing a standard JavaScript call just isn’t acceptable. 

The line was ‘delete a;’ where a was null.  I was trying to reproduce the error, but in isolation it seems to work.  Why does it crash Chrome but not consistently?  I’m currently assuming it’s to do with Chrome trying to be smart around garbage collection that is not thread safe. 

Never mind whether the syntax used is good form, JavaScript should not crash the browser.  And since it crashes the browser, it doesn’t throw a JavaScript error, and has to be debugged from an external debugger like Visual Studio.

Final Thoughts

My biggest issue is that we’ll end up in a world supporting multiple codecs for audio and video to support different browsers, increasing cost of implementation, and reducing budget for innovation.

It’s not all doom and gloom, but for the discussed issues, and others, I feel that there is no short term win. The LCCD (lowest common common denominator) consistently will be the target platform.

Nobody Likes A Space Chicken, Everyone Should Love HTML5

Posted by Vaughan on Mar 15, 2011 in Coding, Games, HTML5, Music | 1 comment

Over the last few weeks at work I have been head down involved with building a fun HTML5 game for EMI titled ‘Way Out Wars’.

Way Out Wars is a fun game for casual gamers, and provides the much sought after challenge for veterans of the ‘space chicken music discovery typing shoot ‘em up’ genre.  The game was built in pure HTML5, with some heavily modified impactjs as the core engine.  Lots of long hours spent tuning nanoseconds off particle render times.

My best is 75 tracks back to back for around 44 million.   Go play it at http://www.wayoutwars.com … preferably before reading the rest of this post to give insight.

Some things achieved in HTML5 that were pretty cool:

• Real time usable particle effects engine we had to dumb down because it was just looking too busy (yet awesome).  At one stage we had smoke, jets, trails, explosions, musical notes, and swarms.  Unfortunately you couldn’t see the game.
• Infinite playlist – Depending on your browser, since Chrome mysteriously dies
• Music discovery that’s fun – Songs you hate, songs you like and songs you don’t know, that you can review and purchase.

Some pleasant discoveries:

• HTML5 rocks.  It’s definitely a platform for the future, however it’s not necessarily the be all and end all.  But the game has no browser dependent coding.  It does however have code that checks for issues that may occur in some browsers, there isn’t any code that goes ‘if IE do this, if FF do that’. 
  NOTE: This does happen for audio however since Firefox hates MP3.
• Impactjs rocks!  In the end we probably didn’t need it as much as we thought, but it did so much heavy lifting in the beginning it allowed us to experiment and play around with ideas.  We simply wouldn’t have had a product as far advanced without it.
• HTML5 benchmarks don’t coincide with real world scenarios.  Simply ignore them until real world tests turn up.  Every benchmark I do IE9 doesn’t come out on top, but all of our experience with the game has been IE9 is way out on front, with no IE9 specific tuning in sight.  Someone who is familiar with graphics pipelines who understands the concepts behind draw calls, fill rate etc.  needs to give HTML5 the same treatment.
• As such, IE9 rocked, and we were pleasantly surprised.
• Opera is amazing, although I’ll probably still never use it.  It came in 2nd performance and stability wise.
• Firefox and Safari were stable, however their performance lacked.
• Chrome was fast, however it’s stability lacked.
• Hardware acceleration rocks.  Browsers without it will die slowly as user experience becomes encumbered by poor performance.
• The iPad did load it once, but it got too big for it.  This however is promising for HTML5 moving forward when the processing power of these devices steps up. 

Some discoveries that were as fun as being jettisoned into the sun by space chickens:

• Having lots of <audio> elements on a page can cause issues. Clean them up, delete them, and do everything you can to remove any trace of them. This was common for all browsers, with the impact having different results in each.  But cleaning up the audio elements makes all the browsers behave.  And whilst Chrome will still go silent after about 100 songs, without doing this it will crash after 57. 
• Oh, and be careful deleting i.e. ‘delete obj;’ audio objects in Chrome, you can crash the browser and all open Chrome windows will stop working.  I think Chrome tries to do garbage collection on audio elements no longer in use.  A quick check ‘if(obj != null) delete obj;’ tends to be stable.
• Any browser that doesn’t support MP3 needs to fix that.  It is a bug, not a feature. If every music site in the world has to re-encode their audio to OGG, they will ignore browsers that require it, or simply be ignorant to it. Firefox needs to wake up.  Media companies are going to be staring at mobile devices, and Firefox is the last thing their IE and Safari based offices will test in.
• Firefox 3 is antique, Firefox 4 feels like a classic, that still goes well, but won’t keep up for long. A shame.  This feels like a Firefox bash, but it has just been the reality we’ve been dealing with.
• Chromes instability.  Chrome is fast, yet buggy. We discovered a critical error that would happen on the 57th track crashing Chrome. After writing a universal piece of code that wouldn’t crash Chrome, we found that at some point, chrome refuses to play audio, and kills audio across all chrome tabs and windows, with no error message.  This came as a surprise to me, and over the coarse of 3 weeks Chrome has been superseded by IE9 now as my default. 
• Safari underperformed.  Of the big names it was the worst performer.