We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexDiscussionGeneral Discussion,  Status › Processing vs. C++
Page Index Toggle Pages: 1
Processing vs. C++ (Read 1747 times)
Processing vs. C++
Dec 21st, 2009, 6:23pm
 
Hi,

I am a structural engineering student interested in creating algorithmic patterns, making visual outputs to some programs I have written (in C++ and Matlab), etc. and I have been looking for a good program/programming languages that can help me accomplish this efficiently with regards to time.

I have some experience with C and C++ (through programming courses), but in that experience I have never had much exposure to doing graphics (2D or 3D). I have the impression that it is going to require quite a bit of hardwork to code graphical output algorithms, although I bet the possibilities of things I could do using these languages would be far greater than with Processing. This because they are low level programming languages in comparison with Processing, and thus I can potentially have more control to some of the capabilities of my programs. For example how it communicates with Matlab, etc. Speed and performance bonuses are also another huge plus point, don't large Java applets tend to be a little slow?

Anyways, as I said, I am a student and perhaps I don't know much of what I am talking about, but I am wondering whether it would more worth my time to learn more about graphics processing using C++, rather than Processing?

Thanks.
Re: Processing vs. C++
Reply #1 - Dec 22nd, 2009, 1:49am
 
Having access to low level layers doesn't necessarily give more possibilities, particularly in the field of graphics, which is more about abstract notions (geometry, algorithms) than hardware access.
Beside, when needed, Java can use C/C++ libraries, via JNI or JNA to access said hardware: that's how we can use OpenGL, graphics tablets, etc.
I have no experience in the field, but in the Exhibition section, you can see people doing wonders in OpenGL by accessing it directly (rather than via the simplified interface offered by Processing).

If you search Matlab on the forum, I am pretty sure you will find some libraries and/or code too.

"I have the impression that it is going to require quite a bit of hardwork to code graphical output algorithms"
Yes, but that's what Processing is about: to do this hard work for you (eg. drawing Bézier curves), to simplify usage of graphics.
Of course, you will find similar graphics libraries in C++ as well (people often mention OpenFrameworks).

"don't large Java applets tend to be a little slow?"
Java fans claim that Java can be as fast as C++ (once the Jit compiler kicked in) or even faster! At least on carefully designed programs that doesn't make lot of garbage to collect... Smiley

Note: if you aim at making applets (running in the browser), Processing is the way to go...

If you meant applets as "small programs" and don't care about running in browsers, Processing has still has an advantage over C++: it is highly portable, you can download a compiled sketch (Processing program) and run it whatever your platform (Mac, Linux, Windows...), while you must compile a C++ program on your computer to make it work. Or distribute lot of binaries. Or at least one for Windows, where compilers are not available out of the box, unlike Unix systems.

Lastly, I would say you wouldn't loose time by learning Processing: the base concepts are quite universal in graphics programming, it is easy and fun to learn, with fast feedback loop (code, click Run and see the result: the save & compile phase is hidden).
And it has a helpful forum! Wink
If really you hit a performance bottleneck (once eliminated newbies' errors like loading a file on each frame...), you might switch to C++, but what you have learned won't be lost.
Page Index Toggle Pages: 1