The background to the tool is obviously Sonant Live, but with some useful changes:

• The soft synth core was rewritten, generally giving better sound quality (better filter logic, supporting sharp transients etc) and faster sound generation.
• There are now four note tracks per pattern, so you can do proper chords.
• An “effects track” was added per pattern, which gives you the opportunity to change any instrument / fx parameter dynamically (quite useful!).
• A new distortion effect was added, giving that powerful dirty sound.
• Also, some functions that I personally did not use that much, or that were just redundant, were removed (for a more compact player routine).

I will continue working on a more public release. In the meantime, enjoy the demo.

1. Adapt the viewport size/scale to the mobile screen.
2. Support touch input.

(I was originally planning to write up some notes on WebGL performance and precision considerations too, but I’ll save that for a later post).

Viewport size

Mobile browsers are quite different from traditional desktop browsers when it comes to how the page size is handled. Instead of using a page width equal to the browser window width, mobile browser typically use a virtual page size that is much larger than the mobile screen, and let the user zoom in and out to be able to both get an overview of the page and easily focus on the interesting parts.

When you make a game or demo, you typically want to fit your canvas/page to the screen of the mobile device and disable zooming. This serves two important purposes:

1. User interaction is much easier if you don’t have to pan around to see the entire screen and find buttons etc.
2. Performance! You don’t want to render more pixels than you need, especially on a mobile device with limited GPU & CPU performance.

The solution is to use the viewport meta tag, like this (for instance):

<meta name="viewport" content="width=device-width,
 maximum-scale=1, minimum-scale=1, target-densitydpi=device-dpi">

Doesn’t look too cryptic, does it? Perhaps worth explaining though is the target-densitydpi=device-dpi argument. It basically tells the browser to bypass any zoom settings and use a 1:1 mapping of your pixels onto the screen (most browsers use a zoom factor > 100% on devices with high pixel densities).

You can find a very good description of how it works here: An introduction to meta viewport and @viewport. The viewport meta-tag is supported by all mobile browsers that I have tried (Opera Mobile, Android browser and Firefox for Android).

Here is an example page with and without the meta viewport tag:

• No meta viewport
• With meta viewport

You should be able to spot the difference quite easily on a mobile device. E.g. try to zoom both versions of the page.

Touch input

Typically when you design an interactive web app, you add support for mouse and/or keyboard input. Unfortunately, that is not of much use on a mobile device. What you want is to use touch input events instead.

Essentially, you use addEventListener to catch touchstart, touchmove and touchend events. In the JavaScript event handler you get an array of touch positions (yes – full multi touch support), each containing the properties clientX and clientY. For instance:

function touchHandler (e) {
  e.preventDefault();
  for (var i = 0; i < e.touches.length; i++) {
    var pos = e.touches[i];
    // Do something cool with pos.clientX, pos.clientY ...
  }
}

function init() {
  var c = document.getElementById("canvas");
  c.addEventListener('touchstart', touchHandler, false);
  c.addEventListener('touchmove', touchHandler, false);
  c.addEventListener('touchend', touchHandler, false);
}

With this information, you can easily map touch events to your in-game UI elements or click on or aim at objects in a 3D world, for instance.

Here is a simple example: touch events. Touch on the screen, and the HTML 5 logo should move to that position.

The recently released Opera shiny demos also has a nice example of touch input: Touch tracker.

Now, let’s make some great mobile apps!

Try it here (compressed) or here (“safe mode”, no compression, with error checks etc).

I have to admit that the design is kind of simple. One of the reasons is that I mostly focused on fitting it all into less than 4096 bytes.

If you want to know more about how I did it, read on… I hope that this post will inspire more people to try out the slightly odd art of 4k JavaScript demo programming.

Strategy & Goals

The goals were, quite simply: make a multi-part WebGL demo with synthesized music, and make it fit into less than 4096 bytes. The strategy was equally simple:

• Use Sonant Live to create the music.
• Use Shader Toy to design my GLSL shaders.
• Create a simple framework in JS to play the music and run the WebGL stuff.
• Finally compress it all with Google Closure Compiler & CrunchMe.

To be able to use several shaders, and still keep the size down, I decided to make good use of the DEFLATE encoder (used by CrunchMe) by making the shaders as similar as possible (meaning a lot of repeated strings that get magically compressed away). Another solution could have been to make some sort of shader builder system (similar to how it’s done in Muon Baryon), but the former approach seemed simpler.

As for what to display, I decided to go for some simple fragment shader based ray tracing. Showing several different parts became a simple case of switching between different shader programs along a time line, like this:

parts = [
    [30, 6], // Tunnel
    [45, 2], // Mirrored slow
    [60, 1], // Wild
    [75, 0], // Basic
    [90, 5], // Even wilder
    [105, 4], // Mirrored fast
    [120, 7], // Tunnel
    [135, 3], // Sepia mirrored
    [9000, 0]
];

var prg = p[0]; // NOTE: This is the first part
for (var i = 0; t > parts[i][0]; i++) prg = p[parts[i][1]];
gl.useProgram(prg);

I toyed around with different combinations of shaders until my compression pipeline gave me a result of somewhere between 6K and 8K. That’s when I started optimizing…

Optimizing Code – Part 1

The first step taken was to minimize the sound synth. I essentially did three things:

1. Remove parts of the music data that wasn’t actually used (such as unused patterns).
2. Remove parts of the sound generation code that wasn’t used, based on the instrument settings (e.g. notch filters weren’t used at all in my tune).
3. Since I was using WebGL, the demo already required typed arrays, so I changed the slightly bulky CanvasPixelArray code to use Int32Array instead.

This gave some significant savings. Rationale: If you start out with a generic solution (e.g. the Sonant music synth in this case), strip it down as far as possible based on your specific needs.

Compression

The CrunchMe compression tool was great, but I was sure that it could do even better. After looking around for different alternatives to the zlib DEFLATE implementation, I finally arrived at Ken’s PNGOUT tool. Now, it’s not open source, but making my CrunchMe tool call the command line tool to do an extra compression pass was simple enough (hey! all tricks allowed!).

This gave me another 100-200 bytes. Rationale: Use the best compression tools available, event if it means that your build system gets a bit “funny”.

Decompression

Apart from doing compression, the CrunchMe tool adds some decompression code to the final code. Here, I mainly did two things that helped remove quite a few bytes:

1. Generate code more dynamically. In particular, I replaced generic expressions like a.length and x.width*x.height with constant expressions.
2. Pollute the global name space (no closures, no vars).

Rationale: Write and generate specialized code, and don’t care if you pollute the global name space.

Optimizing Code – Part 2

At this point, I think I was about 800 bytes from my goal, and started doing all sorts of optimizations. Here are a few tips:

• Your code does not have to do exactly what you first designed it to do, as long as it still looks and sounds OK. Simplify expressions. Do approximations. Drop precision in constants.
• In the same sense, your GLSL code does not have to be correct – you will always get a result! Very subtle changes can create quite interesting effects. For instance, the over-bright second tunnel part is the result of changing a + to a – in a distance calculation equation.
• The Closure Compiler will rename your variables & functions to shorter names. However, it will not shorten names of public APIs (e.g. document.getElementById), so stay away from those and/or find shorter variants that do the same.
• The Closure Compiler will not touch the GLSL code (obviously). Mangle the code yourself (or use a GLSL minification tool). Use short names, and find short GLSL representations (e.g. length(a-b) is slightly shorter than distance(a,b)).
• Utilize the DEFLATE algorithm as much as possible by using similar constructs across your code (e.g. prefer using only cos() instead of mixing sin() and cos()).
• Forget code structure & OO programming. Merge all classes and name spaces! This removes code and usually helps the Closure Compiler to do a better job.
• When you’re close to your goal, do silly things like re-arranging your code and changing non-critical constants to help the compression algorithm find that sweet spot. For instance, changing a constant 9999 to 9090 helped me get below the 4096 limit for the first time.
• And as usual (in the 4k arena): size matters more than speed!

Result

So, the result is an HTML file (32 bytes) and a JavaScript file (4060 bytes) for a total of 4092 bytes. You can see the un-compressed original source code here: frank-unpacked.js.

System Requirements

Theoretically, this demo should run in any browser that supports WebGL, provided that there is adequate hardware support. It has been tested in Chrome, Firefox and Opera 12 alpha under Linux and Windows on NVIDIA, ATI and Intel graphics cards.

If you run into problems with the 4k version, try the “safe” version (at least it should give you some error message if it fails).

Note to Windows users with Firefox or Chrome: You may experience a bug in ANGLE (something like “Shader@0x0644E000(49,145): error X3000″) if you don’t force your browser to use the OpenGL back end rather than the DirectX back end (Firefox: about:config > webgl.prefer-native-gl = true, Chrome: chrome.exe –use-gl=desktop).

Note to Firefox users: The demo may appear to have a poor video refresh rate, due to a bug in the HTML Audio currentTime implementation. Try Chrome or Opera for a more fluent experience.

The Original

So, what is Muon Baryon? It’s a Windows 4k demo originally created by Youth Uprising, Ümlaüt Design and Outracks. More precisely, it’s the winner of the Assembly 2009 4k contest (so it’s a bit old – but still one of my absolute favorites). You can find out more here.

The HTML5 Port

Now, Muon Baryon was low hanging fruit for an HTML5 port, since:

1. Most of it is written in GLSL, which is available through WebGL.
2. The most complicated non-GLSL part was the music synth, and it has already been ported to JavaScript.

So, to begin with I started out converting the remaining C code to JavaScript, which mostly consisted of replacing things like glUseProgram() with gl.useProgram(), etc (a no-brainer). I also had to replace the handy desktop OpenGL call glRect with slightly more bloated vertex buffer code. When trying it out for the first time, nothing worked (black screen)… of course. I suspected the GLSL code and inserted the following lines after compiling the shaders:

if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS))
    alert(gl.getShaderInfoLog(shader));

I quickly realized that the original GLSL code was written for the older desktop GLSL 1.x (using ftransform etc), while WebGL uses GLSL ES, which has dropped a few functions. Here are a few things I had to do to convert the GLSL code to GLSL ES:

1. Replace ftransform with a “custom” position attribute (quite simple, since the demo didn’t use any transformations).
2. Include the line precision highp float; in the fragment shaders.
3. Replace the while-loop with a fixed length for-loop, i.e:

while(g<1.){ ... }

becomes:

for(int j=0; j<999; j++){if(g>=1.)break; ... }

Not sure about how good this solution is, but at least Firefox and Chrome do not complain. Another thing I did was to make the shader resolution independent (the original was hard-coded to a certain screen resolution). Other than that, it was quite straight forward work.

The Result

The size of the original Windows demo was 3977 bytes. I did not expect to be able to squeeze the JavaScript port down to 4k, but I hoped to get it below 8k at least. And the final result, after using Google Closure Compiler and CrunchMe to compress the code, is: 5846 bytes!!

The un-packed code can be found here: demo-unpacked.js

…and the (unreadable) packed code can be found here: demo.js

Getting it to run

Ok, I have tried this in Firefox 5 and Chromium 13+ under Ubuntu with an NVIDIA 9600 card (fairly old by now), and it works just fine.

Windows users may find that it will not work by default (seems to be an issue in the ANGLE GLSL->HLSL conversion). To make it work, enable the OpenGL back-end.

In Firefox, go to about:config, filter out “webgl” and change webgl.prefer-native-gl to true.

With Chrome, you have to start the program with an extra argument, like this: chrome.exe –use-gl=desktop.

Some time ago, I came across Sonant, which is a very specialized tracker. Its main purpose is to create songs that can be used in tiny demos, where the size of the song data plus the player software must not exceed a couple of kilobytes (for comparison, an MP3 file is usually several megabytes).

For various reasons, I decided to make a JavaScript port of Sonant, and the result is:

Feel free to try it out!

The “Why?”

Why make a synth tracker in JavaScript? The top reasons were probably:

• I already had the synth implemented – so the editor was the next natural step.
• I wanted a Linux port of the Sonant tool (which was originally a native Windows app). What better way to do it than in JavaScript?
• Push the limits of current browser technology (i.e, can it be done?).

Note: There have already been some attempts at doing online trackers, for instance the Flash port of Skale Tracker (nice, but Flash) and apparently an HTML 5 synth (has anyone ever seen this live?).

The disclaimer

Just to be clear:

• Sonant Live is still beta (functions are missing, the user interface is not optimal, and there are bugs).
• It is a minimal synth that’s designed for production of music for minimal demos (i.e. do not expect to find a fully fledged omnipotent music studio).

The wish list

One of the goals of making this tool was to explore what can be done with current browser technologies. Throughout the work, I’ve come up with a few wishes for the future directions of browsers:

• Low latency audio API – The current HTML audio element was not really designed for real-time interactive audio. In fact, it acts more like a subset of the video element, which in turn seems to primarily be a replacement for Flash video players (such as the one used on YouTube). With a proper audio API, such as OpenSL ES (WebSL, anyone?), interactive music and game apps would be much more compelling. For instance, the JavaScript synth in Sonant Live is fully capable of producing audio in real-time, so with a “real” audio API it would be possible to get instantaneous playback.
• Better optimizing JIT compilers – As pointed out by Erik Möller in a blog post, you can get a great deal of performance gain by just eliminating property accesses and common sub expressions. In fact, I roughly got a 2x performance win (on all browsers) just by pre-loading common object properties and expressions in local variables. These are well known compiler optimizations that should not have to be performed by the programmer. Now, I realize that the situation is a bit more complicated for a dynamically typed language with setters/getters, but my point is that without those compiler optimizations, bad programming practices are actually encouraged.
• Typed arrays – Life would just be so much simpler if high performance typed arrays were common place. For now, I had to resort to using the CanvasPixelArray trick, which gives me 8-bit arrays (while I’d like to use 16-bit arrays).
• More flexible web workers – The message passing paradigm may be great and fail safe and all, but it really does not cut it for passing huge amounts of data between workers (in my case, I’d like to create the multi-megabyte audio data in  a worker, and pass it to the UI thread). Shared objects would be much more efficient (read only or mutex locked, etc).
• Better URL handling – I suspect that in most browsers, the internal URL handling is optimized for URL:s that are at most a few hundred characters long. For short URL:s, keeping a few duplicates around and traversing the string is cheap, but then a 50MB URL comes along… For instance, when I tried to export a WAV file from Sonant Live, Firefox 4 peaked at 1.6GB , Opera peaked at 2.8GB, and Chrome peaked at 1.1GB and puked (Chrome processes seem to have an upper memory limit of 1GB).

The future

The future is not to see… However, some things are obvious candidates for the future of Sonant Live.

First, the GUI is far from complete. For instance, there are some missing functions (copy/paste, undo, etc), and it would be nice to make the editor usable on mobile devices too (e.g. tablets). It would also be nice to make the tool more interactive (e.g. sound playback while pressing keys on the “piano” for easier instrument tuning).

Another area of improvement is the synth. As it is now, the synth is 100% compatible with the original Sonant tool, which I consider a feature rather than a bug. However, it is quite limited, and there are several simple improvements that can make the synth more powerful (even if minimalism is to be preserved). Some ideas that I have are:

• Richer oscillators – e.g. up to 8 oscillators with different detune settings, which can give quite rich sounds (e.g. check out the Superwave P8 VSTi synth, which uses such tricks).
• Better polyphony – supporting several note columns per channel would make it easier to do things like chords.
• Effect commands – e.g. control instrument and effect parameters dynamically from the pattern.
• Distortion – cheap operation, fat sound.
• Drums – Hmmm… Something should be done to spice up drum sound generation.

These changes would not make the song data noticeably larger (at least not if you compress/deflate it, which is the typical use case), nor would it make the player routine much more complicated.

Another area of improvement would be server-side storage of songs (they are usually less than 1KB compressed, so no problem with disk quotas), so that you can easily access all your songs from anywhere, and publish them for others to enjoy, etc.

The challenge

Feeling inspired? Since Sonant Live is quite minimalistic, it is a bit of a challenge to create good sounding music with it.

So, if you make your own cool song or groovy instrument, I’d like to hear it! Until I get some sort of song submission form up, you can post an URL to your song file in a comment to this post (I can grab it and delete the comment). If it’s good, I’ll include it in the song list on the front page.

It’s currently a beta-release, but with some patience and training you can get it to do wonderful things. So try it out now: http://sonantlive.bitsnbites.eu/

The most annoying limitation right now is the lack of a progress bar (you get kind of a progress indicator in Opera – but not in other browsers). Haven’t solved how to do the music generation in a web worker yet (for instance, I use a 2D canvas context in the synth, which I think isn’t possible in a Web Worker).

Out of curiosity, I did some benchmarking of other browsers as well (this time on a quad core Xeon running Ubuntu 11.04 64-bit). Again, I tested the tune from the Muon Baryon demo (you can get the song file here if you wish to try it yourself in the online player/converter).

For reference, I ran the original demo (assembler optimized) in Wine (I believe it should perform as in native Windows, but it uses 32-bit machine code instead of the 64-bit machine code in the browser JIT:s).

Results

So, here are the results (lower is better):

Conclusions

Well, Opera is ahead of the competition here (it’s twice as fast as Firefox 4!), but Chromium isn’t far behind.

Also worth noting is that Opera is even faster than the native original synth. While this may sound amazing (yes, I think it is!), please remember that the comparison is not really fair. For instance, the original was optimized for size, not for speed (the JIT compilers in the browsers probably optimize more for speed), and as I mentioned, the original runs in 32-bit mode, while the browsers run in 64-bit mode.

I found the SNT tune here, and ran it in Opera in my new online Sonant player (check “Play Now!” if you wish to play the song in your browser), and guess what:

Native asm synth: 43s
JavaScript synth: 47s

That means that the JavaScript synth is less than 10% slower than the hand optimized native assembly language synth!

The code has been released under the zlib/libpng license, so use it as you wish. Many thanks to Jake Taylor (Ferris / Youth Uprising) for making the original Sonant synth available.

To make your own music, use the simple Sonant editor tool (it’s a Windows tool, but it works well in Linux/Wine too).

I still haven’t made any tool for converting the song data to JavaScript. There’s also an online tool available for converting binary Sonant song files (.snt) to JavaScript song files that can be played by js-sonant.

Happy hacking!

In this post, I’ll go through some techniques for creating self extracting, compressed JavaScript programs.

Since this is quite a lengthy post, here’s an outline as an overview and for quick navigation:

• Why compress JavaScript?
• The Google Closure Compiler
• Selecting a compression method
  • Existing libraries
  • Using liblzg
• Handling binary data
  • Base64
  • Latin 1
  • UTF-16
  • The downside to UTF-16 encoding
  • Conclusions for the liblzg approach
• Doing even better – PNG
  • The PNG idea
  • The decompression logic
  • Conclusions for the PNG approach
• Wrapping it up – CrunchMe

Why compress JavaScript?

There may be several legitimate reasons for compressing your JavaScript files. The most obvious is probably to reduce network bandwidth, which can be achieved with HTTP compression (i.e. by using gzip compression between the server and the client at the protocol level).

There are, however, some less common cases where you can not, or are not allowed to, rely on HTTP compression. The use case that originally triggered my interest is the somewhat artificial JavaScript file size limitation of certain demo contests. For instance, the WebGL 64k contest has the following rules:

• Submission file size MUST be ≤ 64k (65,536 bytes)
• No external requests, everything must be inlined in the JavaScript

Pay close attention to the second point: all assets, such as images and music, must be inlined in the JavaScript source code, and according to the first point, the source code must not exceed 65536 bytes. Those are quite challenging limits!

In order to make an interesting program, you will certainly want make good use of those bytes, and that calls for compression.

The Google Closure Compiler

First things first: There is a great tool from Google called the Google Closure Compiler. The closure compiler will basically trim down your JavaScript code to a minimum by:

• Removing all comments and unnecessary white-spaces.
• Renaming variables and properties to shorter names.
• Refactoring expressions and constructs into a more compact form.

Needless to say, any attempts at compressing JavaScript source code should always start by using the closure compiler.

With that said, this article will focus mainly on taking compression even further by applying binary compression methods to the already compact code produced by the closure compiler.

Selecting a compression method

One of the main problems that we face when we want to compress a JavaScript program is that it must be able to decompress itself, which means that the decompression code must not take too much space, or the gain from compressing the original program would be lost!

Another problem is that the binary compressed data stream must be stored in the JavaScript source somehow (more on that later).

Existing libraries

Since the decompression routine must be small, existing (efficient but large) decompression libraries such as JXGraph and js-deflate are disqualified (the decompression routine from the latter, which seems quite minimal, weighs in at 4924 bytes when run through the Google Closure Compiler, which is a bit on the heavy side).

Using liblzg

My first solution to the problem was to use the liblzg compression library, which was specifically designed to enable a light weight decompression routine. As it turns out, the decompression routine fits into about 450 bytes of JavaScript code (with a potential of becoming even smaller with some tweaking), which is clearly acceptable for our needs.

Handling binary data

This brings us to another problem: how to store binary data in a JavaScript source file.

Base64

The tried and true method for storing binary data in text files is of course base64. However, since that scheme is only able to store six data bits per text character, we get a data growth of 33% (assuming an 8-bit character encoding)! That data growth will severely damage the compression ratio, so we ought to find a better method.

Latin 1

The first method that I tried was to use plain Latin 1 encoding – i.e. just put the compressed byte data into a JavaScript string in a Latin 1 encoded JavaScript source file. Obviously, that will not work without some tweaks, since there are several byte values that are forbidden in such a string (0-31, 39, 92, and 127-159, to be more precise).

By substituting invalid byte codes with two valid characters, and some “clever” shifting of codes to minimize the occurrences of invalid codes (based on the statistical content of liblzg compressed data), the data growth factor could be reduced to about 5-10%.

Surely, we can do better than that?

UTF-16

Yes we can! Please note that while in Latin 1 encoding there are 26% invalid code points (in the 0-255 range), UTF-16 only has about 3% invalid code points (in the entire 0-65535 range, only 2151 code points must be avoided).

So, let us use UTF-16 coding for our packed JavaScript program! A 2-byte BOM in the beginning of the file will ensure that the browser understands that we use UTF-16 (it’s actually even safer than Latin 1 encoding, which can be misinterpreted as UTF-8 by some clients or text-editors).

Now we can just pack two bytes from the compressed data stream into a single UTF-16 character, and again have a fall back for invalid code points (use two valid UTF-16 characters to encode two bytes that would otherwise make up an invalid code), giving at most a data growth of less than 4% (in the case of liblzg compressed data, the figure is usually less than 1%).

The downside to UTF-16 encoding

There is one severe downside to using UTF-16 encoding: the decompression routine must be encoded in UTF-16 too, which means that it will take twice the space (i.e. over 900 bytes)! For small files, that may even make the final file larger than with Latin 1 encoding.

But fear not, the solution is near: we can pack the decompression routine!

How? Well, let’s use the same trick as for the binary data: pack two characters into one UTF-16 character. The decompression routine has a nice property: it’s pure ASCII (only using codes in the range 32-126). This means that combining two consecutive bytes into a single Unicode character will always result in a valid code point (all codes in the range 2020-7e7e are valid UTF-16 codes).

Since packing the decompression routine in a UTF-16 string will never produce invalid codes, we get 0% space loss, and the routine for unpacking the packed string is very simple. Yes, we need an additional unpacking routine, and it has to be in plain (unpacked) UTF-16 form, but it does not add much to the code since it’s very basic. It looks something like this (before mangling it to a more compact form):

var i, c, p = '...packed-string...', s = '';
for (i = 0; i < p.length; i++)
{
  c = p[i];
  s += String.fromCharCode(c >> 8, c & 255);
}
eval(s);

Conclusions for the liblzg approach

So, at this point, we’ve taken the liblzg compression pretty much as far as we can for making a self extracting JavaScript program. In summary:

• A self-extracting JavaScript module (about 600 bytes).
• Fairly well-packed binary data (only about 3% larger than the original binary size).
• Pure ECMAScript implementation (very high cross-browser compatibility).
• Decent compression ratio (though not quite as good as DEFLATE, Bzip2, LZMA, etc).

While we have achieved great results, we can do even better!

Doing even better – PNG

Wouldn’t it be great if we could access some browser API that can decompress DEFLATE encoded data from JavaScript? Most browsers use zlib internally for many different things, but still there is no direct support for zlib from JavaScript…

However, if we are willing to sacrifice compatibility with legacy browsers (e.g. IE 6, 7 and 8), there is a cool trick that we can use (that relies heavily on the <canvas> element): store our JavaScript program in a PNG image file (let each character in the source code be one pixel in the image, ranging from 0-255 in gray scale intensity).

So what good would that do – and how can we use it?

The PNG idea

OK, so a little background on the PNG image file format:

• PNG uses the DEFLATE algorithm for compression (which is the same that is used in ZIP and gzip, for instance).
• The file format is lossless (no pixel values are distorted).
• All modern browsers can decode PNG images when loaded to an Image object.
• We can draw the PNG image to a canvas element and read back pixels using the getImageData() method!

In other words, with the aid of the canvas element, we can decompress a PNG image and extract its contents into a JavaScript String object, that we can then execute (e.g. with eval).

Again, we can use the UTF-16 “trick” for storing the raw PNG image data in a JavaScript string without experiencing too much data growth.

The decompression logic

As with the liblzg solution, we need some decompression code. Only this time it’s not the actual decompression algorithm, but a small program that does roughly the following:

1. Decode the UTF-16 string to a binary “string” (containing the raw PNG data).
2. Encode the binary string as Base64, using the btoa() method.
3. Generate a data URI by prepending a small header: “data:image/png;base64,”
4. Load the data URI into an Image object.
5. In the onload handler of the image:
   1. Draw the image to a canvas element.
   2. Read back the pixel values and put them into a new string.
   3. Execute the content of the string.

The size of this decompression program is roughly the same as the liblzg decoder, but on the other hand the DEFLATE compression method gives us better compression ratios than liblzg (the main reason is that while liblzg only uses LZ77 compression, DEFLATE uses a combination of LZ77 and Huffman compression).

Conclusions for the PNG approach

At this point, and with the given goal (making a fairly small JavaScript source file even smaller), the PNG method described above seems to be as far as you can get with current browser technology when it comes to compression ratio (when including the decompression routine as part of the compressed deliverable).

The key benefits with this method are:

• Reuse the DEFLATE decompression routine in browser:
  • Commonly available (every browser that supports PNG).
  • Quite good compression ratios (JavaScript code compresses well).
• Encode the raw PNG data in a valid UTF-16 string:
  • Very low overhead for encoding binary data in a string (only 3-4%, compared to 33% for Base64).
  • Very little chance for the data to be misinterpreted by the browser.

Wrapping it up – CrunchMe

I hope that you found the compression methods described here useful and/or interesting.

If you want to compress your own JavaScript programs, there is an open source command line tool available called CrunchMe.

Note: At the time of writing this, the tool is still under development (beta), but it should be stable enough for normal use (you will have to compile it yourself, though).