Comments on: Meet Cinder: Free Barbarian Group Code Framework Produces Stunning Work; Q+A

By: Creative Coding Frameworks | ewerx

Creative Coding Frameworks | ewerx — Wed, 07 Dec 2011 05:10:55 +0000

[...] looked into the samples for both and I like the coding style/conventions and API of cinder better. This interview with the creators of cinder explains the ideas behind it and the differences with [...]

By: Margarite Mcnuh

Margarite Mcnuh — Tue, 22 Feb 2011 22:09:49 +0000

I went to a restaurant that serves "breakfast at any time". So I ordered French Toast during the Renaissance.

By: aNdReS

aNdReS — Sat, 01 May 2010 11:13:54 +0000

Hi Peter. which of the two "frameworks" would you recommend for someone who has some experience with processing, max / msp and as3?

By: Peter Kirn

Peter Kirn — Fri, 30 Apr 2010 19:21:30 +0000

Right, but unless I'm missing something, I think what you'd wind up doing is charting the difference in underlying frameworks. For instance, using GSVideo in Processing, it's going to rely on how well GStreamer works, and on that platform. (And with that library, as with some others for Processing, Java is doing less of the heavy lifting; it's just wrapping native code. Ditto the approach of a lot of Python development these days.)

Using Cinder, my understanding is that it uses the native frameworks (DirectX, Cocoa QuickTime) – and those aren't necessarily faster. It's an interesting question; it just might be hard to test.

Incidentally, OF now uses mostly the *same* frameworks. (QuickTime, DirectShow, and unicap/video4linux on Linux). But I suppose you might benchmark, then, what happens once those are loaded into an object inside the framework; that might be very different. (That's where Processing falls apart, typically, which is why libraries like GLGraphics keep that data on the GPU and not only avoid Java, but avoid the CPU!)

I'm open to suggestions / insights here, however.

By: Jaime Munarriz

Jaime Munarriz — Fri, 30 Apr 2010 19:15:42 +0000

Loading images may not make a big difference, but loading big video file is a big problem, even for professional media servers… that would be a good benchmark. Find out wich video formats run smoothly, and detect small pauses at the beggining of the loading process.

By: Peter Kirn

Peter Kirn — Fri, 30 Apr 2010 17:41:13 +0000

@DieTapete: Performance should be quite similar; that'll be more the code than the framework. But there may be more isolated examples that I suppose could be interesting. I think it depends on performance of what!

As for the "hardcore pros," OpenFrameworks is no less "hardcore" than Cinder.

If not for people stumbling into programming, I suspect computers wouldn't exist.

Some of us get more skilled; some of us just continue stumbling, hopefully semi-gracefully.

By: JohnG

JohnG — Fri, 30 Apr 2010 17:12:34 +0000

Looks interesting. Hopefully a Linux version will be available in the near future.

By: DieTapete

DieTapete — Fri, 30 Apr 2010 11:28:04 +0000

Well that would be really interesting if these small updates really affect simple things such as loading images.

But Cinder is a framework programmed by real hardcore pros, that've been in the industry for years and oF was started by designers who just kind of stumbled into programming..

So I think it really is a worth trying out. A performance comparison between the two would be great though. Kyle, you seem like the right man for that job!

By: Creative coding with Cinder

Creative coding with Cinder — Fri, 30 Apr 2010 00:00:39 +0000

[...] by Peter Kirn Creative coding with [...]

By: Kyle McDonald

Kyle McDonald — Thu, 29 Apr 2010 21:50:56 +0000

I think the loadImage example is interesting. The difference in philosophy might be about trusting the OS vs trusting other libraries. How often is an OS update released that significantly changes image loading? Compare this to how often FreeImage is updated. FreeImage handles the platform-specific code for OF, while Cinder handles it directly. Some of these things would be great to benchmark, too — I'm not sure whether FreeImage or native OS calls are actually faster for decoding PNGs for example.

I do like Cinder's texture/image separation, but it doesn't really mirror the transparency of Processing's PImage.

Overall, really excited to see this out and to start digging through the examples…