Note: this is a historical document, written as a result of research conducted in early 2011. Things have changed a bit since.

With the recent impasse around Flash and its absence from iOS, I have been asked to investigate the feasibility of attaining a rich gaming experience with more widely supported “pure“ browser technology. To be frank, Flash being a proprietary platform added much to my motivation to show that it is possible to live without..

However, personal bias aside, Adobe Flash not only provides a uniform runtime that is platform agnostic, but also a rich development environment, which makes it much harder to substitute.

As a result, the technology overview resulted in the search of a trade off, where on one hand we have strict platform support requirements, and on the other is the desire to find a comfortable toolset to work with.

First, we have to support as many browser platforms as it is possible. The following are our initial target list:

• Explorer 9+
• Firefox 3.6+
• Opera
• Chrome
• Safari
• iOS MobileSafari
• Android’s WebKit browser

Additionally, there is a requirement to work as comfortably as possible with designer generated artwork.

There are no ripe alternatives to the Flash scripting environment, which allows scripting animation timelines, managing a scene graph, and seamless integration with Illustrator and other tools that artists use to create artwork.

Once off the treaded commercial toolchain path we are on our own to define the export process of graphics from the artist to the front end programmer.

Initially, SVG was examined as a high level language. SVG seemingly has the following advantages:

• Relatively high-level - has its own traversable DOM, to which events can be attached
• Supports complex animation primitives such as animation along a path, shape morphing
• Resolution agnostic (Vector Graphics)
• Posession of something inherently similar to a scene graph
• can use SVG as a native format when importing artwork

With such a list of advantages, one could think that this technology is ideal for our needs. However, the following offsets and undermines these:

• Implementations of SVG vary across browsers in features support
• On some platforms it is quite slow
• the SVG DOM and API was discovered to be complex and hard to use for truly dynamic scenes where objects are instantiated and thrown away.

So it was decided to try a level lower approach with Canvas, and use an abstraction library on top such as Processing.JS

• Canvas is a simple standard and hence almost universally supported on modern browsers.
• Processing gives a degree of abstraction that Canvas lacks as well as an ability to import SVG
• with Canvas we get very fine grained (literally, per-pixel) control over the viewport

Implementing an initial test scene in Canvas/Processing revealed that many primitives that inherently exist in SVG had to be implemented, such as:

• Animation along a path
• Object Mouseover/click detection
• Shape morphing, being complex to implement algorithmically, was done via an Inkscape plugin and exported as a frameset for sprite animation.

These shortcomings would all still be acceptable if in return we got consistent cross platform behaviour that we control to the pixel. Thus, it was decided to proceed with a more real-life example. Unfortunately, this new demo exposed a show stopper for the Canvas/Processing duo: terribly low FPS using Canvas on MobileSafari.

Attempts were made to optimize the demo by removing the background redraw, reducing the amount of objects on screen, removing object textures, all with unsatisfactory results.

By this point, having spent a good deal of time unsucesfully trying to achieve a seemingly straightforward goal forced a rethinking of the methodology. The weakest link in the chain is obviously iOS & other slow-CPU mobile platforms.

On these devices, fast graphics are achievable only with the help of native hardware acceleration. And it seems that in MobileSafari, only the HTML DOM gets that treat.

So the last blackjack table demo was re-written again, this time using HTML & CSS3, this time with sound and some transparency effects.. and - Success! As an immediate result, MobileSafari performance improved.

After further reading and specialized optimizations, the framerate was made very smooth. In iOS 4.x MobileSafari is only partially accelerated, and careful choice of DOM manipulation methodology is needed to squeeze the most out of this browser.

Personally, I was surprised to have been capable of achieving all of the requirements of a graphically intensive scene with “just” CSS transformations and HTML. While busy looking for a silver bullet in the form of an advanced technology, the bread and butter of web programming went unnoticed until other options were exhausted.

This is not to say that Canvas & SVG do not have their place. But with the above realistic goals, SVG is more suitable for complex but rather static diagrams, and Canvas simply doesn’t pull it on the current generation of Apple mobile devices, leaving the scene for just one tech: CSS3.

Incidentally, our choice, dictated by the platform’s low common denominator, forced us to iron out our own custom artwork digestion & montage process. But that’s subject for another article..

The code examples found in this article are available for download off the writer’s GitHub account:

• https://github.com/guyromm/svg-test - initial SVG test
• https://github.com/guyromm/processing-test - initial Canvas/Processing test
• https://github.com/guyromm/processing-casino-test - BlackJack table demo, Processing (table.html) & CSS3 (table2.html).

article tags:

games,flash,css3,svg,canvas,processing,processing.js,browser,web,html5,javascript,webkit,mobilesafari,ios,apple