Yep, your editor uses Processing. I had been working with textures using a library called GLGraphics and advoating the same to everyone I met - and now the functionality is in Processing proper. Here I am messing with textures live. Photo: Brigitte Faessler.

Yep, your editor uses Processing. I had been working with textures using a library called GLGraphics and advoating the same to everyone I met – and now the functionality is in Processing proper. Here I am messing with textures live in my own work. Photo: Brigitte Faessler.

It’s been a long time coming, but Processing this week has reached 2.0, a major landmark release. For graphics, video, data, and usability, it’s a big leap forward.

The big story here is that the creative coding tool is both faster and simpler. An OpenGL engine, built by GLGraphics developer Andres Colubri, now powers everything. That makes extraordinary feats of graphic wonder possible (with shaders and the like), but it also irons out frustrating inconsistencies between renderers. The narrative is similar for video. Andres Colubri’s GSVideo library handles the video work, with high-performance HD (and function with the shaders) for those who want it, but at last simple “just play video” functions work as expected.

And on top of all this, there’s a JavaScript mode for people who prefer that language and native delivery in Web browsers – no plug-ins or Java needed.

It hasn’t been updated yet for the final 2.0 release, but the Changes document is a great overview of all that’s changed in Processing 2.0:
http://wiki.processing.org/w/Changes

The full changelog goes into greater detail. Even this 2.0 release includes a bevy of bug fixes.
Revisions at GitHub

You might have missed some of these links as they’re now after a call for donations on the downloads page. That call is non-mandatory, though, and once you click past it, the download functionality on the site works the same way it always has.

Andres Colubri also has a couple of detailed stories on how shaders work, from the alpha/beta process – though very relevant now. For instance:
Shaders in Processing 2.0 beta

A must-read is a story he wrote during Alpha, which explains retained and immediate mode for those trying to get lots of performance, as well as some crucial details on how 2D rendering and points and lines work, among other tidbits:

OpenGL in Processing 2.0 alpha 5 [ignore that alpha bit - this is the article you should be reading right now]

Excerpt, for those 3D geeks:

Immediate and retained modes in P3D are complementary: when the geometry is highly dynamic and changes every frame, the former is probably a better approach as the PShape objects would need to be updated often anyways. This will bring the performance down to the levels of the immediate mode, or even lower, since the PShape object has a slightly more complex update mechanism. In contrast, big static geometries are good candidates for retained mode rendering.

For graphics quality, there are still the occasional wrinkles in Processing, owed largely to Java and its quirks. The dream of a single renderer isn’t quite there yet: P3D is available, mainly for backwards compatibility, and P2D is what you’ll want to use to get the best-looking two-dimensional stuff. And Java still poses problems: the new graphics libraries are delivering serious performance, but you will see some graphics quality oddities here and there (thanks to Oracle), and things like making MIDI work can be hopelessly buggy (thanks to Apple and Oracle).

But this is an extraordinary work. If that’s not immediately apparent, fire up some of the glitzier video and OpenGL 3D demos, and you’ll see what I mean. Far from threatening Processing’s trademark simplicity and friendliness to non-coders, those improvements narrow the gap between what you imagine and what the tool will do.

If you’re still learning Processing, there was a great discussion in comments on our last Processing story:
Creative Coding, Evolved: Processing Nears 2.0 Release With Hot-Looking Beta 9

processing.org

  • Mattijs Kneppers

    Happy to hear that Processing is evolving. It’s unfortunate that real-time processing and garbage collection are never going to form an ultimate combination. It would be great if someone came up with a 100% strongly typed language like Java (and all the IDE benefits that come with it) that is not based on a garbage collection memory management model.

  • r4dian

    Can anyone elaborate on “things like making MIDI work can be hopelessly buggy” before I take the plunge ? Does this only apply on Macs ?