Hacker News Reader

Comment by thesnark | Hacker News Reader

Having never used Cinder before, why would someone choose it over processing?

Amazing demo form one of Cinder's co-authors: http://roberthodgin.com/cymatic-ferrofluid/

He says that he started with Processing, so I'm guessing that at some point he felt limited by the performance he could get out of it.

Wow! That is some beautiful artwork!

Speaking as someone who develops addons for these, it's much easier to take my C libraries and wrap them for cinder/openframeworks, then it is to either JNI or create an IPC layer (usually via OSC, http://www.opensoundcontrol.org) into processing, too. Yay laziness. :)

Much in the same way that Processing can be compiled to work on Android, Cinder can be compiled to work on IPhones & Ipads.

Also, I think Cinder has a bit more of a direct approach to OpenGL, whereas Processing has built up a simplified layer on top of JOGL to make doing the more common things easier.

It's C++ - so you get value types and operator overloading. Pretty useful for this kind of programming.

(I bet there's command line support too :)

performance, probably.

I wonder what a fair benchmark test would look like. Would it boil down to an argument of C++ vs Java for floating point operations?

I attended various talks by Ben & Casey at Eyeo, and they mentioned the new 2.0 series of Processing including a lot of great new OpenGL improvements by Andres and others, and that the new GL framework shows performance near OF. In another talk, Ben mentioned prototyping something in Processing, and then porting it to OF for speed.

I'd say that in general we'll see this all matter less and less, what with more GPU type stuff happening, and with the advancements in the JIT and code translation in general.

The third alpha release for the 2.0 series they talked about Eyeo is out: http://code.google.com/p/processing/downloads/list , http://code.google.com/p/processing/source/browse/trunk/proc...

even if Processing 2.0 does make perfect use of the GPU that distinction only covers the render phase. Calculating collisions for a large number of objects will still be significantly faster in C++. So like nearly every situation in software, it all depends what you're trying to do.

For computation-heavy apps, probably. For others it'd probably come down to something at the framework level, such as the efficiency of the OpenGL bindings or event/callback infrastructure.

Reply on news.ycombinator.com