Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

Processing Visualization Language Ported To Javascript 171

Posted by kdawson from the time-to-buy-stock-in-noscript dept.
Manfre writes "On his birthday, John Resig (creator of jQuery) has given a present to developers by releasing Processing.js. This is a Javascript port of the Processing Visualization Language and a first step towards Javascript being a rival to Flash for online graphics content. His blog post contains an excellent writeup with many demos."
This discussion has been archived. No new comments can be posted.

Processing Visualization Language Ported To Javascript More

Processing Visualization Language Ported To Javascript

Comments Filter:

  • Heh AvP comes ot mind here (Score:5, Funny)

    by Uncle Focker ( 1277658 ) on Friday May 09, 2008 @11:28AM (#23351576)

    This is a Javascript port of the Processing Visualization Language and a first step towards Javascript being a rival to Flash for online graphics content.
    Whoever wins, we lose.

  • 'polished turd' (Score:3, Insightful)

    by teknopurge ( 199509 ) on Friday May 09, 2008 @11:32AM (#23351636) Homepage
    This is some great work....

    but this is like a polished-turd. Flash doesn't exist anymore to do animation or dynamic graphics, it exists to run fast. JS engines were not designed to process this kind of data efficiently, as seen by your CPU graph when running the demos.

    I don't want to take away from the work, because it's a slick hack, but it's not the right tool for this job.

    Regards,

    • Re:'polished turd' (Score:5, Insightful)

      by AKAImBatman ( 238306 ) <<moc.liamg> <ta> <namtabmiaka>> on Friday May 09, 2008 @11:35AM (#23351694) Homepage Journal

      Flash doesn't exist anymore to do animation or dynamic graphics, it exists to run fast.

      Wait, are we talking about the same Flash? Because I've done a lot of Flash and Actionscripting, and "Fast" is not even in the vocabulary. Software rendered graphics pipeline? Check. Slow VM interpreter that makes Java 1.0 look fast? Check. Lack of direct rendering APIs? Check. Focus on animation at the expense of dynamic scene creation? Check.

      Granted, Flash 9 is a major improvement, but it is arriving rather late in the game.

      • Re: (Score:2, Informative)

        by teknopurge ( 199509 )
        Flash, when used non-gratuitously, has always run fast for me. Check out http://varriastudios.com/ [varriastudios.com] for a site that illustrates what I'm talking about.

        • Re:'polished turd' (Score:5, Interesting)

          by AKAImBatman ( 238306 ) <<moc.liamg> <ta> <namtabmiaka>> on Friday May 09, 2008 @11:46AM (#23351856) Homepage Journal

          Check out http://varriastudios.com/ [varriastudios.com] for a site that illustrates what I'm talking about.

          A user interface? I think you have a very odd definition of "Fast". All you've proven is that Flash is designed to do pretty animations. Well, that's kind of the point. Not to run "Fast". "Fast" was never a part of the design. Just look up the "Actions" portion of the Flash 8 spec sometime and you'll be utterly horrified.

          That being said, Flash does do animations well. That's what it was designed for. As a result, it has even been used to create games [newgrounds.com]. It never did games all that well, but Moore's law eventually made it possible to come up with some fairly decent stuff.

          Of course, if you're referring to "my Flash animations move faster than my DHTML animation", that's just plain user-error. The Flash animations work better because Flash Studio works out all the timings of the motions for you. If you Actionscripted your motions, they'd come out about the same as they would in Javascript. (And being nearly the same language, it's possible to try the same motion code in both.)

          This issue is what the Javascript PVL is intended to solve. i.e. A standard framework for providing animation/motion with minimal input from the developer.

          • Re: (Score:2, Troll)

            by teknopurge ( 199509 )

            Of course, if you're referring to "my Flash animations move faster than my DHTML animation", that's just plain user-error. The Flash animations work better because Flash Studio works out all the timings of the motions for you. If you Actionscripted your motions, they'd come out about the same as they would in Javascript. (And being nearly the same language, it's possible to try the same motion code in both.)

            Completely and utterly false.

            JS interpreters are not optimized to do image manipulation, DOM updates, etc. Now this isn't to say they aren't moving in that direction, but as of now they are atrocious at these tasks.

            Flash is a completely separate environment from the browser, is vector based and inherently performs animation better. Right now it's always faster(CPU %) to do an animation in Flash then it is to do the same animation in JS.

            Regards,

            • Re:'polished turd' (Score:5, Insightful)

              by AKAImBatman ( 238306 ) <<moc.liamg> <ta> <namtabmiaka>> on Friday May 09, 2008 @12:10PM (#23352228) Homepage Journal

              JS interpreters are not optimized to do image manipulation, DOM updates, etc.

              Whiskey Tango Foxtrot. Optimized for image manipulation? You do absolutely ZERO image manipulation in Javascript. Same with Actionscript. All that is pushed down into the Canvas and Flash rendering engines, respectively. Same thing with DOM manipulations. Sure, you say "insert this item" or "delete this object", but it's the C/C++ engine under the covers that does the heavy lifting.

              People haven't done their own image manipulation since Amigas stomped the earth.

              Right now it's always faster(CPU %) to do an animation in Flash then it is to do the same animation in JS.

              You make that statement, yet you posted a benchmark that showed Javascript to be faster than Flash. I'm rather confused. You do realize that the benchmark you posted below was in millisecond and not operations per second, right? i.e. Lower is better.

              You have zero evidence for your statements. Listen to someone who actually knows something about these platforms. There's no reason why Javascript can't perform the same function as Flash using the Canvas APIs. And you know what? That's not a bad thing. :-)

              • Re: (Score:3, Informative)

                by teknopurge ( 199509 )
                Please check that link again as it appears you ahve misread it.

                Lower is better.

                Got it.

                Array join (array size 1000, 500 iterations)
                JS: FF2 - 375ms, Flash - 303ms

                substring (10000 iterations)
                JS: FF2 - 16ms, Flash - 3ms

                Did you look at the link I posted at all? Even the older versions of Flash were split with JS ~50/50 on the various datapoints.

                I'm not implying it's a bad thing to try, but seriously. Did you even look at the JS code that is your "framework" to this stuff? Let me grab you a piece:


                do {

                • Re: (Score:3, Insightful)

                  by AKAImBatman ( 238306 )

                  Please check that link again as it appears you ahve misread it.

                  Actually, you should check my post below as I explained in detail why Flash lost that handily. The short version is that Flash 9 is not comparable right now because the VM is not in use by many projects. By the time it's in heavy use, FireFox will be using the exact same engine.

                  Did you even look at the JS code that is your "framework" to this stuff?

                  Sure. And the piece you picked (like most of the code) is motion computations. The piece you picke

                  • Re: (Score:2)

                    by ardor ( 673957 )

                    That *could* be heavily optimized with lookup tables, but there wouldn't be much point.
                    Nowadays, lookup tables for log and sqrt are unwise. The CPU has instructions for this, and lookup tables just trash the cache. Random numbers *can* be reasonable as a LUT, especially pseudorandom stuff like Perlin Noise. But your average random() function does not belong in a LUT either.
                  • Thanks so much for all the great information about Javascript. As Doug Crockford says, it's The World's Most Misunderstood Programming Language [crockford.com] Just a few months ago I started a project (in my spare time of course) to see how I could push my knowledge of the language, and I came up with this: Track Attack [primateapplications.com]. It's far from complete, but uses Javascript for everything except sound (which uses an API to flash to handle it). The browser isn't taxed too much (after some tweaking on the music) and it was a fun

              • Re: (Score:2)

                by pjt33 ( 739471 )

                People haven't done their own image manipulation since Amigas stomped the earth.
                I have, working for a company which makes Java games and still supports MSJVM. We wrote our own libraries to do almost everything because there wasn't available library support for it.
          • found this:

            http://www.oddhammer.com/actionscriptperformance/set4/ [oddhammer.com]

            don't know the accuracy, but interesting nonetheless.

            • Re:'polished turd' (Score:5, Insightful)

              by AKAImBatman ( 238306 ) <<moc.liamg> <ta> <namtabmiaka>> on Friday May 09, 2008 @12:17PM (#23352324) Homepage Journal
              I mentioned this above, but I'll reiterate it here. In that benchmark, LOWER IS BETTER. The brand-new Flash 9 VM engine did excellent (as I expected it would), but the Flash 7 and 8 engines were generally creamed by the Javascript engines. Which I don't think is what you're trying to prove at all.

              The secret to the performance of Flash 9 is this little beauty: http://www.mozilla.org/projects/tamarin/ [mozilla.org]

              A fully modern, high-performance, Just In Time compiler that gives the JVM a run for its money. It's an amazing piece of Javascript technology that Adobe has donated to the Mozilla project for inclusion in the next major revision of FireFox. Wonderful, wonderful engine that absolutely no one is using yet.

              See, if you compiled to Flash 7 or 8, you're still triggering the Flash 8 engine. The Flash 9 engine is a complete rewrite that only works with Flash 9 content. So the next chapter of performance wars has yet to be written.

              Q.E.D.

              • Re: (Score:2)

                by MenTaLguY ( 5483 )
                And of course, by the time Flash is using Tamarin, so will Javascript be (at least in Firefox).
              • > absolutely no one is using yet

                Er, except for Flash 9. Which it was originally written for.

                • Re: (Score:3, Informative)

                  by AKAImBatman ( 238306 )
                  I think you missed the point. If your Flash code is not compiled for Flash 9, Tamarin is not used. The old Flash 8 engine gets loaded instead. Since the vast majority of Flash content is still Flash 8, no one is using Flash 9. :-)

        • Re: (Score:2)

          by GweeDo ( 127172 )
          That site is a great example of how not to use Flash. Not one thing there couldn't easily be done with standard HTML+CSS+Javascript. All they have now is a site that is hard to crawl and index and un-usable by the impaired. Go Flash!
          • I used it as an example of how it was much faster for the developer to make it using Flash authoring tools to get the look he was after then using HTML. Of course you could make a similar site using HTML+CSS - that's not the point.

            It also take significantly fewer request to load(i.e. 2) then a normal site.

        • Flash, when used non-gratuitously
          Well, there's yer problem!

      • Re: (Score:3, Insightful)

        by frosky ( 42740 )
        As a longtime Flash developer i can also tell you that wether u use it for animation, GUIs or for basic web apps, the primary appeal to people like me was that Macromedia created avery easy to learn authoring environment. And even as the application grew to include programming and such, its concept of timeline, tweens, movieclips, etc. was far simpler to learn than the alternatives - including MM Director. To me that is the core strength of Flash. So whoever attempts to compete should take that into conside
      • The VM does, however, make most JavaScript implementations look slow -- emphasis on "most".

        Which is why the Tamarin [mozilla.org] project exists.

    • Re: (Score:3, Funny)

      by Uncle Focker ( 1277658 )

      Flash doesn't exist anymore to do animation or dynamic graphics, it exists to run fast.
      So when is Adobe finally going to get around to meeting that goal?

    • Flash is just Adobe Javascript (Score:4, Informative)

      by Anonymous Coward on Friday May 09, 2008 @11:41AM (#23351786)
      Flash itself uses a dialect of ECMAScript (the common parent language of Javascript and ActionScript). So your assertion that Javascript engines were not written to do this is flat out wrong.

      All this shows is just how terrible most browser's Javascript engines really are. Notice, modern browsers do considerably better on these demos than older ones, mainly because so much of the web has shifted to using Javascript and dynamic content, such that JS becomes a limiting factor in usability. Once JS engines have caught up to ActionScript in speed, what more use do we have for Flash? We already have Mozilla working to make use of the Tamarin byte-code engine, which will turn JS from being a slow, interpreted language into being a byte-code compiled language (speed on the order of modern scripting languages such as Python/Ruby and to some extent Java/C#).

      So sorry, Javascript is the right tool for the job. It's the only tool for the job as far as Open Standards are concerned.

      • Flash itself uses a dialect of ECMAScript (the common parent language of Javascript and ActionScript). So your assertion that Javascript engines were not written to do this is flat out wrong.
        A language and it's implementation are two different things. Just because a language has a feature doesn't mean an engine is written well to use it.

    • Re:'polished turd' (Score:4, Interesting)

      by kestasjk ( 933987 ) on Friday May 09, 2008 @12:11PM (#23352252) Homepage
      JS engines aren't currently designed for it, but this is what Canvas (and a lot of HTML5) is all about..

      If you prefer think of this as Processing on Canvas, rather than Processing on JavaScript, because Canvas is the enabling technology here.

      And I don't know where you get off calling it a "polished turd". (Makes me want to poke around your homepage-vertisement, and see if you have a right to make those judgements)

      The Java requirement was always a pain to deal with before, and this "polished turd" removes that and makes visualizations much more portable and easier to play around with.

      Also the moving visualizations have always been CPU intensive, that's the nature of what they are; they're supposed to be easy to create visualizations of data, it's not a video game. It was like this on Java too.
      Note that the static practical visualizations, which take dynamic data, draw the visualization and then end, need much less CPU than dynamic ones like you might see in a flashy demo.

      This is a very good thing, and a very welcome surprise; Processing really does offer something that's pretty unique, and I look forward to seeing more of it. Kudos Resig

  • Second Step (Score:5, Informative)

    by AKAImBatman ( 238306 ) <<moc.liamg> <ta> <namtabmiaka>> on Friday May 09, 2008 @11:32AM (#23351648) Homepage Journal

    This is a Javascript port of the Processing Visualization Language and a first step towards Javascript being a rival to Flash for online graphics content.

    Second step, actually. Apple and the WHATWG [whatwg.org] took the first step by introducing the Canvas API to the HTML 5 spec. That gave web developers the ability to do Flash-like content. This language is the second step, in that it gives programmers a standard framework from which to create impressive animations.

    Kudos to Mr. Resig on a job well done! I can't wait to play around with this project more. :-)

  • Not going to happen (Score:4, Insightful)

    by stonecypher ( 118140 ) <stonecypher&gmail,com> on Friday May 09, 2008 @11:43AM (#23351810) Homepage Journal
    The primary strength of Flash is its single vendor, rigorously portable, rigorously backwards compatible runtime. Javascript is far too fragmented to be a competitor to flash.

    • Re:Not going to happen (Score:5, Insightful)

      by ozamosi ( 615254 ) on Friday May 09, 2008 @12:13PM (#23352278) Homepage
      I know, and so does everyone else.

      You know, I recently heard about a project by John Resig (creator of jQuery) called Processing.js. It's a Javascript port of the Processing Visualization Language, which means it could be viewd as a rival to Flash for online graphics content.

      You should check out his blog post [ejohn.org]

      In case the sarcasm wasn't obvious enough: that's one of the most important things that Javascript libraries solve

      • Re: (Score:3, Funny)

        by Arslan ibn Da'ud ( 636514 )
        In case the sarcasm wasn't obvious enough: that's one of the most important things that Javascript libraries solve


        Wow! A library that helps people detect sarcasm...that IS a killer feature!!!

    • Re: (Score:3, Informative)

      by MightyYar ( 622222 )

      Javascript is far too fragmented to be a competitor to flash.

      The author's most famous project, jQuery [jquery.com], addresses this weakness, though. It is a smallish framework that does a very good job abstracting you from the browser-to-browser differences in Javascript.

      I haven't played with this new toy of his, but it stands to reason that he'll take the same care with it that he did with jQuery.

      In other words, Javascript may be too fragmented, but this Processing language is not... and you write your code in Processing, not Javascript.

  • Javascript being a rival to Flash for online graphics content

    The article submitter has clearly never actually used the HTML canvas object. There's no way in HELL canvas & javascript together could ever approach the render and execution performance of Flash.

    It is very handy to have though, apart, of course, from having to perform kludgery to get it working roughly in IE (by using excanvas.js to emulate the canvas object in VML).

    • Re:Rival?! (Score:5, Informative)

      by AKAImBatman ( 238306 ) <<moc.liamg> <ta> <namtabmiaka>> on Friday May 09, 2008 @12:02PM (#23352108) Homepage Journal

      The article submitter has clearly never actually used the HTML canvas object.

      Oh? I have, and I don't disagree. Of course, I've USED Flash quite a bit too, so I know how God-aweful slow that platform was up until version 9. ;-)

      There's no way in HELL canvas & javascript together could ever approach the render and execution performance of Flash.

      Why not? Flash == Software renderer. Canvas == Software renderer. Actionscript == ECMAScript engine. Javascript == ECMAScript engine. I'm not seeing the issue.

      Hell, once FireFox is on the Tamarin engine, the two platforms will be practically the same!
      • That, and maybe I haven't looked too carefully at it, but I suspect Canvas is not necessarily a software renderer. At least, I suspect it's possible to build a compatible renderer which is hardware accelerated.

        The difference is, of course, that Flash will be hardware accelerated when Adobe damn well pleases, and there's nothing we can do about that.

    • Re: (Score:2, Informative)

      by Manfre ( 631065 )

      The article submitter has clearly never actually used the HTML canvas object. There's no way in HELL canvas & javascript together could ever approach the render and execution performance of Flash.

      I have used the HTML canvas object. It's not on par with Flash 9, which is why I wrote "a first step towards Javascript being a rival to Flash". I styled that to help you with reading comprehension. Processing.js is an enabler that will lower the bar for many developers and give it the attention needed to improve the weaknesses that exist.

    • Re: (Score:2)

      by HeroreV ( 869368 )

      There's no way in HELL canvas & javascript together could ever approach the render and execution performance of Flash.

      You're not very imaginative. Once JavaScript has the same JIT as ActionScript [mozilla.org], the language will be just as fast. And once Canvas has a hardware accelerated 3D API [mozilla.org], it'll be much faster than Flash. 3D content in Flash is extremely slow and takes up a lot of storage space, because it has to be converted to 2D content beforehand.

  • Eric (Score:5, Insightful)

    by erickhill ( 1235704 ) on Friday May 09, 2008 @12:05PM (#23352140) Homepage
    Regardless if this is usable today for client work, this is insane stuff. The first iteration of Flash eons ago had plenty of nay-sayers. He made this over the course of seven months? Bow down, I say. Very impressive.

  • Other than that, Mrs. Lincoln, how was the play? (Score:5, Insightful)

    by Em Ellel ( 523581 ) on Friday May 09, 2008 @12:50PM (#23352778)

    Thus, anything outside of the above (images, pixel processing, and text) should work "ok" everywhere.
    Is it just me or does graphical language that does not fully support image, pixel, or text processing seems a bit.... silly.

    Don't get me wrong, I think its a cool toy I will be playing with, but until it actually works in more than one beta browser, its is no threat to Flash at all.

    -Em
  • has the writer of that claim read chapters 8 and 9 from Flanagan's Javascript 5th ed.? It is a hopelessly messy language that is congenitally unable to do a decent job of OO implementations. Flex has classes in a more normal sense of the word. Sounds like hype. Does the newly offered code somehow bury the variable scoping sloppiness of JS?
    • Why is the distinction between objects that you can inherit from (classes) and ones you can't (instances) so important?
      • I didn't mean to say that was the problem. Its the loosey goosey inheritance mechanism, looks like an aferthought, not sure how you avoid circular dependencies...and the dozen hoops to jump through if you what to imitate the innate data hiding of a real OO language. You have to work to make namespaces and vars are basically global unless they start colliding. The way a function namespace comes from the context of its definition rather than invocation yet NEW requires a function to be supplied as the con

        • Re: (Score:2)

          by argent ( 18001 )
          Ah, yes, I was wondering about the "flex" bit, and I really do prefer a classless model, but I'll grant you that global-by-default is a bugger to deal with for any program more than a couple pages long. If all they did in JS2 was to fix that bit and left the classlessness intact I wouldn't be dreading JS2.

          In Javascript's defense, I don't think it was originally intended for programs more than a couple of pages long.

          Python will be ubiquitous after they redesign the syntax. Preferably towards a Smalltalk-like
          • "dreading js 2"

            quite so. The more lovable and perfect it is, the more disruptive it will be to a staggering volume of interactive bits that legions of coders have tucked into all the pages on the internets. We paid a VERY high price for "run everywhere".

        • and the dozen hoops to jump through if you what to imitate the innate data hiding of a real OO language.

          It's actually pretty trivial to do that, though I would argue it's much better to simply specify, in your documentation, what your public API is.

          The way a function namespace comes from the context of its definition rather than invocation

          That's a feature. It means all functions are automatically closures, which makes for some very cool Lisp-like possibilities.

          Not going to disect your entire post -- whether it was your intent or not, one gigantic paragraph is annoying to read -- but here:

          A quick article [crockford.com]

          Or, check out the YUI Theater [yahoo.com], in particular things like "The JavaScript Programming Language" a

  • (sorry this is tangential to the topic)

    This summer my goal is to start working with Processing. I'm at home in C/C++/Lisp and I have a tiny bit of experience with openGL (probably safe to assume it's worthless though - I pretty much recycled other folks' shaders when I was working with it). Do any folks here have some advice, such as where they started when they began working with Processing? Thanks :)

    • Re: (Score:2)

      by stokes ( 148512 )
      The best resource for learning Processing is just taking apart the example code that comes with it.

      Processing is extremely easy if you have previous programming experience. It's really just Java with a simple IDE and some automatically-loaded libraries; when a Processing 'sketch' compiles, it's actually wrapping it in a Java class and building that.

      • Re: (Score:2)

        by ystar ( 898731 )
        Thanks! I'll start with that advice. I've looked through a little bit of the examples on the main site. I've been feeling too impatient and very curious as to how folks like flight404 are creating these great lighting and texture effects:

        http://www.vimeo.com/935317 [vimeo.com]

        It seems things like that represent a couple years of experience (stuff like the magnetophysics of the ball) but I like to get my hands as dirty as possible, as quickly as possible.

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close