If ever you wanted a reason to move to Firefox………

Posted by Martin P in Development, PACS General      No comments

Aug
23

This is it. The announcement that Firefox 3.1 (current version is 3.0) will include a Just-In-Time Javascript compiler that increases performance of various tasks by an order of magnitude or more is quite significant (some benchmarks here).  It is difficult to find a web site (let alone a browser application) that doesn’t rely on Javascript to some extent.  But JS has always suffered from one issue as a means to deliver business logic – its SLOOOOOOOOOOW.  To get such a performance improvements is welcome for anyone interested in delivering, or comsuming, browser-based services.

But for medical imaging, the announcement(s)  have particular resonance.  I have noted before an approach for adjusting window/level of images in a browser. Such jiggery-pokery is needed because there is no support for such operations in the WWW/HTML standards, so any attempt at such needs to go outside such standards (e.g. ActiveX, Java), or resort to JS (which, again, is SLOOOOOOOOOOOW).  But no more. Does this make Window/Levelling fast enough in the browser?  We don’t need to go very far for an answer.  A screencast of the difference in performance makes very interesting viewing. Just to summarize – using javascript alone, schrep was able to provide a near-real time experience in adjusting brightness and contrast. OK, the size of the image (465×700) isn’t the same as a CR (although comparable to a CT or MR), but it isn’t that different to the size of a view onto a CR.  WADO already supports a viewport concept (so zoom and crop operations are done on the server), so there is little fandoogling to do other than defining the size, position and zoom level of the viewport. After which, it would appear, W/L functionality can be handled with Javascript.

(A note for anyone clicking through to the on-line demo- the javascript seems to have dumped on my browser a little. But then, its a proof-of-concept, and I’m still running FF 3.0 on a box with not as much memory as I’d like, and far too many tabs open. I’ll forgive it, so).

There are other developments of much interest in the FF camp.  Implementation of HTML 5  is to include support for Canvas-3D, which is set to allow for assistance from low-level hardware acceleration for 3D rendering (via OpenGL).  It is important to differentiate between these developments, and the plug-in options such as ActiveX, Java, or Flash.  These are very much robust, fast implementations of standards that other browsers should be EXPECTED to support as well as their own proprietary features.
FF 3.1 is based on Gecko 1.9.1, which is scheduled for a beta-1 feature freeze on 9 Sep, so we probably won’t see a stable release of FF 3.1 until late September at the earliest  but it is worth watching for.