Slashdot Mirror

← Back to Stories (view on slashdot.org)

Introducing JITB — a Flash Player Built On the JVM

Posted by Soulskill on from the stay-as-long-as-you-like dept.

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."

3 of 126 comments (clear)

  1. 30X faster? by strokerace · · Score: 5, Informative
    Let's put this into perspective. Even the author of the software is calling for a reality check that's missing from the summary.

    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.

  2. Adobe has one by Stan+Vassilev · · Score: 5, Informative

    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.

  3. Re:Ironically... by Anonymous Coward · · Score: 4, Informative

    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.