Processing Libraries - Where are They?

Introduction

This was quickly followed by a series of security issues with Java and subsequent over-reactions which mean that, even now, virtually no business or university users can view self-signed applets within a browser anymore. At that point I moved everything over to C# and started working in Xamarin Studio, but did try to keep the Java version reasonably updated as I went.

The image above shows an example application created using these libraries. I’ve implemented pretty well all the standard UI elements such as buttons, icons, checkboxes, lists, tabs, menus, panels, sliders, textboxes and popovers, as well as all the input management for overlaying them on an interactive 3D model. The 3D model components offer a simple scene graph with camera, view and selection classes as well as automated animation and interactive editing features. The detailed implementation in some of the elements is a little bit interesting as I have attempted to unify touch, pen and mouse interaction in the one UI, so I will follow them up in subsequent posts.

I have been keenly following the development of Processing 2 and periodically check how it well it works with my code. Now, with the new release of v2.2.1, it really is starting to look the business again. Thus I recently delved back in and now have a reasonably stable version of my libraries that seem to work pretty well with it.

General Observations

As Processing 2 has evolved, Andres Colubri has done a Herculean job getting the OpenGL performance back up to speed. Rendering in some of the early versions was almost unusably slow. However, with my own reasonably graphically intensive applications, I can now confidently say that v2.2.1 is appreciably faster than using the OPENGL renderer in v1.5.1 - tested with both running the same pure Processing graphics code with no direct OpenGL calls or retained mode features. More importantly, whereas I spent quite a bit of time determining what worked best in the old version, apart from adding a few flush() calls here and there to get it working, I haven’t yet spent any time trying to optimise for the new version.

Also, to achieve code compatibility with Android in the old version, I had hacked together my own Java mode version of the PShape3D class that used display lists instead of VBOs. Yes, management of view transformations is a nightmare as these are done by Processing before rendering in OpenGL, however this has worked really well for me as the same core code can seamlessly use the existing VBO-based class when running in Android mode and the display list version when running in Java mode on a desktop. The latest version of Processing 2 has PShapeOpenGL classes in both Android and Java mode, so this should make my original hack obsolete, and it will be interesting to compare the speed of VBOs against the display lists I’ve gotten used to.

Stroke Weight Scaling

The decision in the new version to apply scaling to stroke weights as well as geometry is still a perplexing one for me. In the reference documentation for the PCanvas.strokeWeight(weight) method, it clearly states that the weight parameter is given in pixels, even in v2.2.1. However, if you use any of the PCanvas.scale() methods, the stroke weights change size within the display. As pixel-based line weight is a fundamental part of OpenGL, it must have taken some significant extra effort to code up this completely new scaled line weight solution.

This one change has caused me the most grief as I use a lot of instancing of scaled geometry as well as zoom scaling in perspective view (rather than dollying in/out). However, I think I have worked out a way to deal with it so I just need some time to hack out the new code. I will probably expand on this a bit in a subsequent post as I think that not making this optional is a real regression for users who work in 3D or want nice crisp charts and graphs on high resolution displays. Some people go to significant lengths to achieve this.

Installation Issues

Working in Android Mode

Of course, getting v2.2.1 to work in Android mode on a Mac with OSX is still no simple matter. I had the same problems as many others, being unable able to find javac and then Android dex giving a BufferOverflowException during a build. The solutions that worked for me were to add a symbolic link to javac inside the Processing 2.2.1 app package and then uninstall the default Android SDK Build Tools 19 and upgrade to 19.1 within the Tools section of the Android SDK Manager.

If you don’t want to read the links to each issue, you can do this yourself by first checking where your Processing application is (usually /Applications/Processing) and your JDK (usually /Library/Java/JavaVirtualMachines/jdk1.7.0_XX.jdk), and then open a Terminal in OSX and enter the following:

cd /Applications/Processing.app/Contents/PlugIns/jdk1.7.0_55.jdk/Contents/Home/jre/bin
ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/bin/javac

Obviously at time of writing I had installed update 55 of the JDK 1.7, so you will need to make sure to change that bit when you enter the commands if yours is different. One good thing though, even though I have applied additional critical updates (in my case update 60), it didn’t change the JDK folder name so you don’t need to update the symbolic link every time you apply a Java update.

JDK 1.7 Breaks Processing v1.5.1 in OSX

I mainly use a machine with OSX Mavericks and a few different versions of Windows/Linux running in VirtualBox. I was having problems getting the latest stable version of JMonkeyEngine to work in OSX, so I stupidly installed JDK 1.7 from Oracle to see if that made a difference. Despite many exhortations that Java 1.6 from Apple and Java 1.7 from Oracle do not conflict, doing this completely breaks Processing v1.5.1 as all you will get from then on is “Error: This Java instance does not support a 32-bit JVM”. The Processing forums are full of people with the same problem but no useful responses other than to simply upgrade to Processing 2.

The problem is that Processing v1.5.1 automatically includes the -d32 compiler switch irrespective of the settings in your preferences file and OSX obviously finds the 64-bit Java 1.7 binaries before the original 32-bit Java 1.6 which should still be there. I tried setting the JAVA_HOME environment variable and adding entries to PATH, but nothing seemed to work. Some people suggested reinstalling the latest Java 1.6 from Apple, but I now still need 1.7 for some other projects I have started.

I did find one brute-force technique that definitely does work. If you temporarily move the JDK 1.7 folder to somewhere OSX can’t find it, then Processing v1.5.1 works fine again. When you are done and need Java 1.7, simply move it back. To do this you will need to use the Terminal and have administrative privileges. All I did was create a folder called JavaBackup within an existing Temp folder that I keep in my user area, and then entered the following at the command line:

sudo mv /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/ ~/Temp/JavaBackup/

Then to move it back again when I am finished, I enter:

sudo mv ~/Temp/JavaBackup/jdk1.7.0_55.jdk/ /Library/Java/JavaVirtualMachines/

Too easy…