Monthly Archives: June 2011

‘Bout Time

This is it: I’m immensely proud to announce the first official release of Jax! It’s been over 8 months in the making, and the framework has spent the last several weeks undergoing strenuous tests in a variety of development and runtime environments. While I can’t possibly claim that it’s utterly bug-free, I’ve done everything in my power, including leveraging the strength of the WebGL community at large, to make Jax the best it can be out of the gate.

I’ve been testing and tweaking the framework for quite a while now, and the feedback I’ve gathered in the meantime is nothing short of awe-inspiring. Literally hundreds of people have been looking at Jax and the various demos I’ve concocted using it, and reports of failure have been generally few and far between. Those reports were analyzed and resolved, usually within a few hours or less.

I just finished running one more test to verify that everything goes well under Windows environments, and I had no trouble with it. I could sit here and make minor tweaks to the Jax internals until the world ends, but the simple fact is that Jax is as solid and robust as I can make it at this time. It’s handled every edge case I’ve thrown at it like a champ, and the only way it can get better at this point is through real-world experience with people doing things with it that I can’t possibly imagine.

Jax is a relatively young framework, but the project is not. I was researching how best to implement Jax way back when WebGL was still a draft specification, changing virtually every day. Back then, the only way to fly was with the latest nightly browser versions and magic command-line flags to enable WebGL support. The research I did in those early days is a large part of what has made Jax possible. In addition, I had started no less than 3 separate projects, all of which were designed to explore the fastest and most versatile ways to make productive WebGL development happen on the grand scale, far beyond simple demos. Jax is the result of that research, the culmination of those projects.

The Jax code base itself is already four months old. I feel I’ve shown a more-than-reasonable amount of restraint and caution in terms of versioning, which I hope speaks to my commitment to bringing a robust long-term 3D Web development environment to the table.

As I stamp the first major version number onto Jax, I can’t help but feel the excitement mounting. There are a lot of new features that I can’t wait to introduce, and now that Jax is officially shipped, I can get to work on the next batch of awesomeness.

Try out Jax; it’s been a lot of months, and now it’s finally ready for you. If you have problems with it, let me know so I can fix them! Send me all of your questions, comments, hate mail and love letters — I’ll read them all! Promise!

What’s New in Jax – v0.0.0.9

We’re coming down the stretch in preparation for Jax v1.0! I’ve had to draw a line in the sand and decided not to implement any new features following Picking (which was added in Jax v0.0.0.7). I can hardly wait to ship v1.0 so I can start adding in all the new features I’ve thought about since making that decision! But, patience is a virtue, as they say. I’ve decided to release v0.0.0.9 tonight instead of v1.0, and let it ride with the latest batch of changes for a day or two before making the leap to a major version number.

(Update: it’s now 0.0.0.10; I excluded some worthless files from the build, and the gem size dropped from almost 10MB to 100KB! Thought that was worth another release!)

So, what kinds of changes are we looking at here? Nothing too drastic, I assure you; but there are some things that might cause a headache or two if you go upgrading blindly.

As usual, here’s the changelog linkage!

First and foremost, the Custom Shaders Guide is up! Like the Getting Started Guide, it’s pretty comprehensive; that makes it big, but hopefully not too big. It answers every question I could think anyone might ask about Jax shaders. The guide is still in draft form and I’ll continue to polish it up over the next few days, but I wanted to get it out there as soon as possible since there’s been quite some interest about how to go about writing your own shaders lately.

Now I’ll talk about changes in the actual code base: I’ve altered how Jax specs are run, with particular emphasis on shader specs. Generating a new Jax application will now generate an additional helper file at spec/javascripts/support/helpers/jax_spec_environment_helper.js. I’ve moved all of the Jasmine set-up code into this file, and altered the generated spec/javascripts/support/spec_layout.html.erb file to call the helper.

In addition to cleaning up the layout file, this helper actually serves a useful purpose. It defines a global SPEC_CONTEXT which is now automatically managed by the test suite. No longer do you have to manage your own contexts from one spec to the next! It’s now completely transparent and totally automated — and not to mention safer. Since it runs on a completely different <canvas> element than the visual tests, you don’t have to worry about it causing problems. And since it’s automatically disposed and then reinitialized between tests, you don’t have to worry about individual specs tainting the context!

There’s a downside to this change, though. If you’re working on an existing Jax project, you’ll need to generate a new project and copy these files into your existing project; also, if you have custom shaders, you’ll want to remove the context initialization and disposal from the shader tests. (Other tests aren’t affected.) Sorry for that — though you were warned about it being pre-release software!

The rest of the changes were pretty minor, and only worthy of a footnote. Bugfixes here and there, and the error messages when a glDrawStuff function fails now include the exact enum name, so you don’t have to look it up the hard way. Stuff like that.

I’ve also got 2 more live demos on the way! I’m hoping to release them over the next day or so. Hold tight!