TraceMonkey: DOM, Canvas, Opensource and more
Brendan Eich promised that trace based JIT’s will give us killer JavaScript speed and now we have seen the fruit of his labour with TraceMonkey (adds trace smarts to Tamarin-tracing).
A lot has been said already, but I am really excited about much more than the “look at how we run Sun Spider”.
The DOM matters
Although it may not sure in todays code drop, Brendan gets that you have to care about the DOM and not running while(1) { cheasyTest(); }:
- He gets it: “As we trace more of the DOM and our other native code, we increase the memory-safe codebase that must be trusted not to have an exploitable bug.”
- If DOM code comes out of native code and into JavaScript, it matters: “TraceMonkey advances us toward the Mozilla 2 future where even more Firefox code is written in JS. Firefox gets faster and safer as this process unfolds.”
Canvas
You know Canvas? It’s days are coming… fast, as John Resig mentions:
One area that I’m especially excited about is in relation to Canvas. The primary thing holding back most extensive Canvas development hasn’t been rendering – but the processor limitations of the language (performing the challenging mathematical operations related to vectors, matrices, or collision detection). I expect this area to absolutely explode after the release of Firefox 3.1 as we start to see this work take hold.
Opensource matters
None of this could be accomplished without the great side of opensource. TraceMonkey uses Tamarin-tracing, which enables it to build on amazing code.
TraceMonkey itself is opensource, which enables the SquirrelFish team say, to check it out. And, vice versa. This will keep the competition going along nicely.
This kind of competition is phenomenal for us, the consumers of the Web. Performance is key in 2008, and Web developers get to laugh all the way to the bank.
Thanks guys!
August 22nd, 2008 at 11:36 pm
Dion,
I’ve done a lot of work optimizing code to run on Canvas, and in my experience, there is much to be improved outside of making Javascript run faster. Leaving aside the fact that the API is missing some fundamental operations (text, image processing ops like convolutions, retrieving current transformation matrix, faster pixel ops, etc), it seems to me that the implementations could still be leveraging more hardware acceleration than they currently are. In particular, on the iPhone, drawImage() and canvas scaling seem to add up to 100ms of overhead.
There’s alot of stuff you get in Java2D/Java Advanced Imaging, CoreImage, or DirectX/GDI that would be nice to have in Canvas. No matter how fast they speed up the JIT, having to emulate platform features in Javascript is going to be less than ideal. And there’s alot of work that Flash’s vector engine accomplishes in native C that will remain slow implemented in pure JS.
I’d love to see real, photoshop-like and imovie-like apps implemented in the browser, but I think it’s still a pipe dream. They’re just barely doable in Java, and there you’ve got efficient access to image data.
I think what we may see is scenegraph libraries like CAKE that provide SVG-light style functionality, but using Canvas and running faster than SVG manipulation, but I don’t think we’ll see JS+Canvas spanking Flash.
August 22nd, 2008 at 11:44 pm
Ray,
Man, have I told you that you are my favourite commenter? Wow, I really appreciate how much you add to the conversation.
I agree, we aren’t there yet. However, for certain use cases I have been amazed at well Canvas is performing. Text is there now (using moz specific, and FF head has it as the canvas standard) and hoepfully more will come.
More and more of the work is being passed through to the lower level implementations. I think the future could be quite bright.
Cheers,
Dion
August 23rd, 2008 at 3:25 am
Dion,
Please pound on the WebKit, Opera, and IE8 guys to get transformed text there as well!
BTW, According to the WHATWG spec, the measureText() method seems less than useful since it goes not give atleast a rough bounding box (through which the text will not escape). I currently simulate measureText() by placing a hidden DIV element on the page, putting text in it, and asking for the bounds of the DIV. Too bad this can’t be accelerated and provided as standard. Granted, this won’t happen rotated/transformed text on FF, but on WebKit with CSS transforms, it might (haven’t tried it).
August 23rd, 2008 at 6:34 am
Canvas is nice. Still, I don’t I get it why bother with Canvas if Internet Explorer don’t implement it? Is there a point in forcing users to use Firefox to run your application? Then may be it’s safer to bet on Java new Applet plugin: won’t reach all users either, but at least Java is then fast, has rendering hardware acceleration, high levels of abstractions (via JRuby if you like) an libs and is even cross browser. So what the point about Canvas? I’m just curious.
August 23rd, 2008 at 9:19 am
Raphaël,
We are getting there with IE. There are projections via old VML, new Silverlight, and even by putting the Mozilla code in place to render it. Also, hopefully Ie does the right thing and puts native support into IE8.
With abstractions like raphael (your name :), and dojo.gfx, they take care of it all for you.
Cheers,
Dion
August 23rd, 2008 at 12:45 pm
.
… and, of course, if you’d like to do image-processing or video-editing or such in the world’s browsers today, then…. ;-)
jd/adobe
.