Slashdot Mirror
Introducing JITB — a Flash Player Built On the JVM
MBCook writes "Joa Ebert has started working on a new program called JITB. Announced in a talk at FITC San Fran, it's a Flash player written to use the Java JVM to run ActionScript, and in a simple graphics test case (making 1 million calls to flash.geom.Point) was 30x faster than Adobe's Flash player. There is an impressive demo video on YouTube showing the point test."
A tool that Oracle and Adobe can take for a legal Menage a trois
Does anybody know of screen capture software that reproduces the "I'm recording video of my monitor using my shitty cell phone" effect?
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
From his site:
Update: Please do not think that this implementation is 30x faster than the Flash Player developed by Adobe. One(!) microbenchmark is never a number you should count on. I would like to make clear that I never said this.
So an implementation of a language that only implements 1% of the functionality is less bloated and faster than the full implementation when running one very specific test? No fucking shit. I'm one of the first to bash Flash at any opportunity, but I'll wait and see how well this performs once it actually has some functionality before I start laughing at Adobe.
Also available via html5/h.264:
Enable html5 playback @ http://youtube.com/html5
If this really works, then we will finally get Flash to work on BSD and 64 bit version of Linux.
Yes, HTML5.
Try to watch Youtube on a laptop with a really slow wireless connection. Then switch to an iPad.
Adobe (back then Macromedia) used to ship Flash in two version: native binary and Java version in the days when Java applets were popular. They stopped developing it around the time Flash 4 was out, because the tables have turned: Java applets were going down, while Flash was going up.
The article never mentions any reason as to why this player was developed, and I'm struggling to come up with a reason myself, as it's easier to port the native runtime to any platform, than maintain an independent copy in a constant "catch up" mode.
An African Swallow... or a European one, I don't remember which one is slower... WHAAAAAAH (thrown into cliff).
Whenever in an argument, remember this.
You're almost certainly going to get modded into oblivion for question His Holiness Steve Job's HTML5, but it's worth pointing out that you're absolutely correct, and it's because Flash allows for bandwidth-sensitive downloads and HTML5... doesn't.
Basically, a Flash app can start streaming a movie and see how fast it's connecting at. If it's connecting too slowly, it can switch in mid-stream to a lower bandwidth stream and continue playing as if nothing happened.
HTML5 can't do that.
Strangely enough, QuickTime can do this automatically. But QuickTime isn't HTML5, and so if you're serving up an MP4 file so that it plays in both Chrome and Safari, well, you won't get that feature. You have to create the special QuickTime specific index MOV file, and that can only be done using QuickTime Pro.
Which, incidentally, is what you're "supposed" to do when serving content for the iPad and iPhone.
This means very little. Anyone can make a subset of a language faster then a full implementation.
The Ruby world has been through this recently: Someone comes out with a fantastic runtime that supports 1/8 of the ruby language, and it's 10x faster then everything else!
There's lots of hype, but as development continues the other runtimes get 2x faster, and the new magic runtime gets 5x slower by actually supporting the whole language, and the new magic runtime is now the same speed as the rest of the field, with less compatibility and more memory usage.
So color me skeptical, until this runtime supports the whole language, including transparent overlays and all the stuff that the Adobe guys claim makes Flash slow.
Even the author of this article will tell you this. He recently added:
Update: Please do not think that this implementation is 30x faster than the Flash Player developed by Adobe. One(!) microbenchmark is never a number you should count on. I would like to make clear that I never said this.
That being said, If we're stuck with Flash for at least the near term, I'd like to see projects like this, Gordon, and Smokescreen take off and perhaps improve our choices in runtimes. I just don't expect magic.
Blessed are the pessimists, for they have made backups.
... java is slow and a memory hog. (for the sarcasm impaired, yes, I'm joking).
please excuse my apathy
HTML5 can't do that.
HTML5 only specifies the source URL where to get the media from. Doesn't specify how to play it nor exactly how to download it.
Of course you could just implement it in a dumb straight forward way : like download the whole damn file and just play it.
But some data containers, like the OGG container with is pushed forward by OSS at least for Vorbis and Theora (and could be used for VP8 too) are designed in such a way that different chunks can contain different level of details (think like a progressive JPEG). A more advanced software could download the metadata and then only selectively download parts of the file that contain the chunks that it can play within the bandwidth limit. (Think : only downloading the first part of a progressive JPEG which contain the lower resolution data).
I don't know if Matroska (the preferred container for VP8 codec as part of Google/On2's WebM) can do it too.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The article never mentions any reason as to why this player was developed, and I'm struggling to come up with a reason myself
I would think that the JVM itself is the main reason.
Flash uses Actionscript, a variant of ECMAScript, just like Javascript.
To run it fast enough, an implementation needs a fast and nice actionscript engine.
One possibility would be to get a Javascript engine like Google's V8, Mozilla's Trace- / Jaegger-Monkey, Adobe's own opensourced Tamarin, etc.
The other possibility is to use a well known and well optimised VM like Java and compile the Javascript into Java bytecode. This makes the process more complex, but leverages the years of JVM development.
Also the second advantage is that lots of hardware contain already a functionning JVM : Lots of phone have Java EE, Android has the Java-like Dalvik (which can run java byte code after a transcoding), etc.
as it's easier to port the native runtime to any platform
Saddly, the main reference implementation of Flash is closed source (except for the Tamarin engine).
So for a port you have 3 possibilities :
- wait for Adobe to port the latest official player. Saddly they aren't doing it for lots of different architecture
- port yourself one of the open source implementation (Gnash, LightSpark, Swfdec)
- use a multi-platform player (Java)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]