html5cube–The HTML5 Cube
I’ve been wanting to do a puzzle cube with video on each side for a long time as a tech showcase. Finally I got bored enough to do it.
html5cube is a 3D puzzle cube with video on each side. Make sure you’re running IE9, Opera, or at least Chrome, and go check it out at html5cube.com.
I haven’t extensively ripped it apart in many browsers, other than IE9 and Chrome. FIrefox got a real workover, and after Firefox 3 or 4 simply not able to play nice, I’ve ignored them. Their performance is crap, and I think that ends up causing all sorts of race conditions. I might look into it in the future, but this experiment isn’t for Firefox.
Lessons learnt:
- IE9 still outperforms the other browsers when juggling more than 1 thing (matrix maths + lots of drawImage calls)
- webm is much fatter than H.264 and OGG. I increased the encoded images by 4x, H.264 ended up SMALLER, OGG went up by about 20%, and webm went up about 3x. As such the worst video quality is webm since it’s the low res version.
- <video> playback varies between browser in terms of CPU priority. This means that CPU intensive JavaScript calculations can chop the video around, and other browsers the video chops the JavaScript around. Yet another metric to balance.
- Three.js is excellent.
- Canvas rendering (as per my previous post) leave visual artifacts and different approaches in each browser. Anti aliasing, and texture resizing all differ and it causes changing visuals. IE9 tends to look the best, but I think that’s half good management, half convenient accident.
- It’s on canvas, and I think every browser that has WebGL support is ignoring canvas performance completely. I still am surprised at Chrome’s poor scaling with pixel count.
- Cubes are still very very awesome.
- Cubes that have video in each side are much much harder to solve.
HTML5 Video Codec Selection in JavaScript
I was looking around for a nice video codec selection via JavaScript, and possibly writing my own if I couldn’t find one. Outside of the video players, there isn’t a library either.
It is possible to interrogate the <video> element to find out what codec support it has. The problem is that it is only reliable in Opera. All other browsers are completely unreliable.
But there is an easier solution if all you are trying to do is load the right video via JavaScript. With video selection being an option within the video tag itself, you just need to create the <video><source/><source/></video> via JavaScript. Assuming your video files are encoded correctly (and the server is sending back the right mime types) you’re set!
// Takes a file with no extension, and
// creates a video element for webm/h264/ogg
// and plays it
function createVideo(fileNoExt)
{
var newVid = document.createElement(‘video’);
// IE, Safari, IOS
var h264 = document.createElement(‘source’);
h264.setAttribute(‘src’, fileNoExt+’.mp4′);
h264.setAttribute(‘type’, ‘video/mp4′);// Firefox
var ogv = document.createElement(‘source’);
ogv.setAttribute(‘src’, fileNoExt+’.ogv’);
ogv.setAttribute(‘type’, ‘video/ogg’);// Chrome
var webm = document.createElement(‘source’);
webm.setAttribute(‘src’, fileNoExt+’.webm’);
webm.setAttribute(‘type’, ‘video/webm’);newVid.appendChild(webm);
newVid.appendChild(h264);
newVid.appendChild(ogv);document.body.appendChild(newVid);
newVid.play();
}
I’ve been using this approach for a few things, and it seems to work every time.
NOTE: The order of source elements is important. iOS 3.x has a bug where it only looks for the first element, so H.264 should always go first.
Read MoreA Standard HTML5 Standard Standard
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.
Read MoreNobody Likes A Space Chicken, Everyone Should Love HTML5
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.
This Blog Post Best Viewed In Netscape Navigator
</2 years not posting>
HTML5 is great. I’m really looking forward to it, but with all it’s standardised extended capabilities comes a new frontier, browser performance.
I’ve been playing around with IE9’s GPU accelerated HTML5 SVG, and performance blows Chrome and Firefox out of the water. Throw in a few physics engines and play around a bit more though, and you start to notice the performance spread shifting dramatically. Because IE9 is doing all the display calculations in GPU, the choke point is the physics engine, and that choke point is the JavaScript engine, so it generally slows down proportionately to world object calculations (once the world step calculation time exceeds your physics time step delta).
With Firefox and Chrome, you start to notice massive differences early on. Chrome starts to slow down, but it flies compared to Firefox, which seems to struggle pushing everything through the physics steps and the graphics rendering at a decent frame rate. If I was to rate the performance in the ‘Eyeball HTML5 Benchmark TM’ it would be 100, 60, 20 to IE9, Chrome, Firefox.
But this isn’t a browser war rant, this is a rant about the problem this creates on the developer side.
At the moment the main considerations when doing an advanced website are limited. The questions asked by clients are generally straight forward.
Will this run on the PC’s of our users (CPU, resolution etc)? Will it render correctly in all browsers?
I’m not talking about a bleeding edge benchmark of performance, but something consumer mass market oriented. My concern is that with the new era of HTML5 RIA apps emerging, the performance gap in rendering and JavaScript, are we going to re-enter a world of ‘Best Viewed in Netscape Navigator’ ? WebGL is coming in Chrome and Firefox, but Microsoft has no public announcement it is going to come with IE9. The underlying engines when they arrive will differ drastically in performance. SVG, Canvas, WebGL, and HTML rendering performance may vary between browser, CPU, and GPU.
But even on the day that Chrome, Firefox, and IE have relatively equal performance metrics, with mobile internet usage projected to outgrow desktop internet usage by 2014, the problem gets exponentially complex when catering for mobile devices, tablets, and the rest of the crew.
The cost of development and testing goes through the roof. Creative designers have been trained to think in terms of Flash / Silverlight and the predictable performance metrics, and development houses without foresight will start pumping out amazing creations that only work under lab conditions.
And while as a geek I will write something to push the GPU in IE9, I don’t see it as a compelling reason to develop bleeding edge clock cycle pushing code until the all browsers are up to speed. I do see GPU acceleration as a reason to use IE9 so hats off to Microsoft for getting that in there. I’ve found it much snappier than any of the other browsers at the moment. But throwing something out there publicly knowing that in FIrefox it will crawl along slowly is not compelling at all.
I’ve been hearing a lot about the future of gaming and apps, and simply put, it’s a long way off for now. The technology is there, but the industry is not. While the future may hold some exciting things for HTML5, the short to mid term holds some nice standard ways of doing things that for the past 10 years have been HTML and CSS hacks. And that’s enough to get excited about for now.
PS – Any other browser I haven’t mentioned above is still relevant for this discussion, and the ‘if everyone just used X’ argument simply reinforces the issue.
PPS – IE9 GPU acceleration can be seen working best with SVG, and not to be mistaken with WebGL. 3rd party 3D libraries I’ve found just come down to JS execution speed, the rendering is the baby step in those scenarios.
Read MoreFlickr
|
Recent Comments