20.0 available

20 still has some glitches in it, but I think it's far enough along for people to bang on. The big changes in 20 are the new download interface triggered by that giant "arrow" in the toolbar (in fact, if you downgrade to 19.0.2, it "sticks") and official support for getUserMedia, which we now support, too. I'll talk about that in a bit. Downloads and release notes, my preciouseses. The fix for IndexedDB offline storage databases affected by issue 213 is included, but read the release notes first!

The glitches relate to two things: I need to patch our 10.4 accelerated canvas to support the new canvas compositing operators (should be straightforward), tracked in issue 216, and we still have some JavaScript regressions to shake out (issue 215), particularly in v8-crypto. However, these regressions already shipped in 19, and y'all said that was faster than 17, so you have no one to blame but yourself! (And, uh, me for not keeping an eye on the numbers.) David Anderson from Mozilla has given me some ideas where to look, and the good news from the AWFY grid is that even if I did absolutely nothing the numbers would get close to where they were before (remember, we are the red JM+TI line on those graphs, and 20 comes from that period of time where there is a "bump" in the line around December 2012). I reverted the most painful change for this version, and I'm attacking the other changes next. These backouts are being exported as stand-alones so that if I get IonMonkey working we can just jettison them, since this is merely temporary right now for the undesirable situation where we need to live out our lives in a pain multiplier the methodjit/JaegerMonkey compiler for JavaScript acceleration.

(Sharp readers may have noticed I've said very little about SunSpider times, although they are similarly affected. That's because I'm doubtful Mozilla is optimizing much for them anymore and they are now practically microbenchmarks on modern CPUs. What benefits the V8 benchmark does not necessarily benefit SunSpider, but I'm not sure that the latter is necessarily salvageable at this point. We'll see.)

Video and audio support through getUserMedia is, as previously mentioned, fully supported for the moment. NB: I haven't decided if this will be supported for certain in TenFourFox 24 -- it depends on whether Mozilla or Google guts our QuickTime C API support along the way. For now, it is. I tested it with my iSight FireWire camera, which worked, and my Orange Micro iBOT, which didn't. Please try it with your Mac's devices on the test page and post your experiments to the video support wiki page. I'll make reasonable efforts to support devices that are not technologically constrained, but no guarantees that your favourite device will be one of them, of course.

On the future technology and port-killer front, Mozilla is not stopping their JavaScript work with the IonMonkey JavaScript just-in-time compiler, which is why it's so important for me to finish (hey, looking for a project? my partial work on IonMonkey is in our 20 changesets, which you can help with!); their next frontier is OdinMonkey, which makes we wonder where I can get some of the hash they smoke in these Mountain View naming meetings. OdinMonkey is not another JIT, which is good, because if they were already working on the next one I would be throwing in the towel here. Instead, OdinMonkey is the overtestosterated Norse ape god incarnation of asm.js, an attempt to make a minimal subset of JavaScript that can be distilled down to very fast code.

Our interest in OdinMonkey is not to be able to write the next 3D engine, because we don't have WebGL. However, other applications are being compiled for it using the Emscripten toolkit, which takes LLVM opcodes and emits equivalent JavaScript compliant with asm.js/OM, and I don't see any reason why we shouldn't be able to run these too. It should be possible to really rev performance since there is much less code complexity involved, and if they add the SIMD features they're promising we can finally implement AltiVec acceleration in JavaScript (sorry, G3 owners, you'd get equivalent slower code here). However, I can also smell serious endian hell coming from this when someone writes code assuming little endian byte order and we may need to do once and for all what I considered long ago, which is to hide our native endianness from JavaScript and make it look little-endian from the code perspective (using instructions like lwbrx, which do work just fine on G5, by the way). But to make the most of it we'll need IonMonkey, because I'm sure the really awesome optimizations will build upon it.

The port for 21 will start with beta 2, as usual.