One notable problem with Java (and thus Processing) is that, on its own, it’s not the best solution for doing the pixel-by-pixel processing and computer vision / motion tracking / video analysis, as it’s not as efficient for those kind of tasks as C/C++. The motion tracking / computer vision library for processing JMyron is actually written in C++ and wrapped in Java, for instance — though it’s important to note that the ability to wrap C/C++ code in Java is very nice. (And once you’ve done the basic analysis, you can get away with some iterating through pixels in Java/Processing, and it is fast for some related tasks like doing the actual animation.)
But C++ can be a bit unfriendly. There are libraries that are very helpful for doing this kind of work, but you have to track them down. Chris O’Shea of Pixelsumo writes about a new solution that could bring some of the basic ease of use of Processing’s integrated libraries to C++ work, in the form of Zach Lieberman’s new C++ library “OpenFrameWorks”:
OpenFrameWorks at Ars Electronica [Pixelsumo]
I’d keep a close eye on this, as Lieberman’s extensive experience building work that uses these techniques means he knows a lot about what’s needed in the way of performance. But there are some major caveats that mean this isn’t quite “Processing for C++”:
- It’s not out yet: OFW is in alpha-alpha-alpha, and for the moment there doesn’t seem to even be a real download link.
- Java is easier than C++: Perhaps an oversimplification, but Java is an excellent language for people who have never programmed.
- Processing is far easier than anything else: Because Processing uses simplified syntax and does much of the work for you (a bit like the ActionScript environment in Flash, but arguably even easier), you’re shielded from a lot of the grunt work of programming. That’s great for beginners, and even fairly sophisticated programmers often use it for fast “sketching” and prototyping. OFW doesn’t seem to be headed in that direction; it combines a number of libraries as Processing does but lacks the simplified syntax and development environment.
- You can always wrap C++ code:
I’m still interested in going the opposite direction: using C++ libraries within Java, etc., and even wrapped for Processing as JMyron is. One issue, though: OpenGL access isn’t terribly easy in Processing, in particular, and can even cause some headaches in Java, so if you’re programming 3D art, OFW could wind up being a lifesaver, when it’s a little more finished.
A couple of years down the road, OpenFrameWorks could be catching up to Processing, and like Processing, it’ll be open source. But in the meantime, I’m sticking to Java and Processing. And maybe I’ll go to a Sun conference. No, that’d probably be deadly dull.
We’ve been getting mightily geeky here, so for those of you who are lost, let’s just close with: “move along, move along, nothing to see here yet, go do that Processing tutorial and all will be made clear.”