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."
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.
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.
It just proves that if there is anything that executes slower than java, it is flash!
today is spelling optional day.
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 ]