The Processing Development Environment (PDE) is currently tested on:
- Mac OS X 10.6
- Mac OS X 10.8
- Windows XP (latest service pack only)
- Windows 7 (32-bit and 64-bit)
- Ubuntu Linux 10.04 (32-bit)
- Ubuntu Linux 12.04 (64-bit)
These are the operating systems that are on machines at the Processing Release Testing And Quality Assurance Center (the PRTAQAC, which bears a suspicious resemblance to Ben's apartment).
At the moment, OS X 10.8 gets the most testing because that's what's used for development. If you run into trouble, you've gotta let us know, the PRTAQAC is badly understaffed.
Also check out the Troubleshooting page for platform-specific issues.
Windows is generally the the best platform for running Java applications. It's not because we like Windows (we don't) but that's just how it is.
We are not supporting or testing with Windows Vista. We're going straight from Windows XP to Windows 7.
Testing with Windows 8 has not started.
The 32-bit version of Processing is recommended on Windows.
It's not possible to use Processing with Windows 98, ME, or 2000. Recent Server editions are not supported, though they should work.
Mac OS X
Java on Mac OS X has always dragged behind other platforms.
- As of Processing 2.0, OS X 10.8 receives the most testing. We also do basic testing on 10.6, but you should consider upgrading because even Apple is aggressively dropping support for earlier OSes.
- After 2.0a9, the minimum system has been set to 10.6. Technically, many features might work on 10.5, but I just don't have the ability to test 10.5, 10.6, 10.7, and 10.8 on 32- and 64-bit, and we're getting more bugs that are showing up that are specific to 10.5. In particular, we're requiring 10.6.8, because earlier releases were buggy. And if you're on an OS from 2009, you should at least have it up to date.
- In my opinion, OS X 10.7 is useless and generally should be avoided. At least 10.8 fixes up some of the goofiness of 10.7, and the upgrade is $20. But I really miss 10.6, which was a wonderful piece of engineering. Sniff.
- In 2012, Apple turned over further development to the OpenJDK project, so we'll eventually be moving to Java 7 which is released by Oracle. We'll keep an eye on how Java 7 develops, and future versions of Processing on OS X will likely include their own Java runtime just like the Windows and Linux versions. This Java 7 download is not ready for prime-time or use with Processing. Please avoid it for now and use Java 6 from Apple.
- Processing is no longer supported PowerPC machines. I've sold my PowerPC Mac, and you should too.
- The key conventions in OS X are closer to other programmer's editors on OS X (TextWrangler, Eclipse, etc). This makes some people unhappy. Those people can manually edit preferences.txt (its location is listed in the Preferences window) to change a line or two:
# The home and end keys should only travel to the start/end of the current line. # The OS X HI Guidelines say that home/end are relative to the document. # if you don't like it, this is the preference to change: editor.keys.home_and_end_travel_far = false # The home and end keys move to the first/last non-whitespace character, # and move to the actual start/end when pressed a second time. # Note that this only works if editor.keys.home_and_end_travel_far is false. editor.keys.home_and_end_travel_smart = true
For the 2.0b8 release, some initial work has been done to support Apple's “Retina” displays. This is not ready for prime time (it should be considered "alpha" quality or worse), but please help test it (and file issues on Github) so that it's ready for the final 2.0 release. While this code will be in 2.0b8, please test by using the source from Github because this is an area undergoing active development. To be clear, Retina support is not available/usable in 2.0b7 or earlier. Even once 2.0b8 is available, please use the source from Git for testing.
To make use of the retina-enabled renderer, use the following on an OS X machine with a retina display:
size(960, 540, "processing.core.PGraphicsRetina2D");
Generally, this should give you nice 2D graphics (smoother type, sharper images if large versions are loaded). If you find quirks, please file an issue on Github.
The goal for the retina version is that everything runs unchanged, but this also means that pixel-related operations will produce ugly results, because they use "low" resolution pixels. This is a list of pixel operations:
- get() and set()
- loadPixels(), updatePixels()
- saveFrame() (and save() in some circumstances)
- copy() and blend()
To improve rendering quality with pixel operations, use:
inside your setup() method. This indicates to Processing "I understand this is a retina display, and that all pixel operations will be 2x the size". This will cause pixel operations to instead work in a "doubled" coordinate space. For the 960x540 example used above, that means that calling loadPixels() will produce a pixels array that's 1920x1080 pixels. Or that get(0, 0, 960, 540) will only return the upper left quarter of the sketch image. But saveFrame() will also give you nice, accurate 1920x1080 images instead of the "fuzzy" 960x540 version that you get without the hint().
This needs a lot of testing, so please help. There may be many bugs.
The long size() command used above is just because this feature is in testing. For the final release, Processing will automatically detect retina support and choose the correct renderer. (It doesn't now because it's not been tested enough, and we don't want to break something major.)
There is no OpenGL support, and we have no idea if/when that will happen. It will depend on the progress of the JOGL and LWJGL projects.
With any luck, the Linux release should work fine by simply changing to the processing folder and typing
On Linux, the Processing application is just a shell script. If you set up a launcher (e.g. in Ubuntu), be sure to set the working directory to the folder that contains the shell script. It's not smart enough to find its own path. (If you can write a version that's smarter, please let us know).
Most problems on Linux come from the version of Java that's included in the download being incompatible with the OS. In that case, remove (or rename) the included ‘java’ folder, and replace it with a usable version of the JDK (not just the JRE!), or symlink it to a full JDK that's installed on your machine. Be sure that the symlink is set up relative to the ‘processing’ shell script such that ./java/bin/java points to the ‘java’ binary. Take a look at the folder structure of the included ‘java’ folder to see how it works.
Due to incompatibilities, OpenJDK is not supported. You'll need a regular Java release downloaded from Sun/Oracle.
The GNU Classpath, GCJ, GIJ combination will not work with Processing. OpenJDK and IcedTea also have problems, particularly with running sketches full screen or with multiple displays or even window sizing. Bottom line: use the version from Oracle.
If you get Processing to run properly, the Sketch → Show Sketch Folder command may not be available. Processing will attempt to find kde-open and gnome-open, and if neither is available, the menu item will be dimmed. To fix this, you must set a launcher for your platform. Add a line to ~/.processing/preferences.txt that specifies its location:
launcher.linux = /path/to/launcher_app
Because Processing is written in Java, it should run on any platform that supports Java 1.6. If you'd like to get it running on BSD, Irix, AmigaOS, BeOS... whatever, do the following:
- Download the Linux version, and replace the “java” folder with versions that support your platform. (See the Linux instructions about linking to a proper JDK).
- Next, mess with the shell script if necessary to get things up and running.
- If you have success, share the details for others.
Users of OpenBSD can use the ports and packages framework to install Processing using the following command:
Please note this package is not created by the Processing team and any possible issues should initially be reported to the package maintainer.
Java 1.6 (or "Java 6") is required to run the 2.0 version of the Processing Development Environment and projects created with it.
If you get an UnsupportedClassVersionError when using a library or other Java code, that means the code was compiled for a later version of Java than is supported by Processing. Recompile this code and set the 'target' to an earlier Java release (1.6 or earlier should do fine) and you'll be all set.
We're not sure when we'll be supporting Java 7. At the end of February 2013, Java 6 will be hitting end-of-life status, which means that no further updates to Java 6 will be made by Oracle. A few notes on the status of Java 7 support:
- Java 7 on the Mac is pretty mediocre when compared to Apple's 1.6 implementation, and it doesn't support retina displays. So we will probably stick with 1.6 on OS X for a while. Also, Apple doesn't support 1.7 on OS X 10.6, which is probably a third of our OS X users. Supporting 10.6 and 10.8, for 32- and 64-bits is already a freaking nightmare. Adding 1.7 to the mix (since we'd need to keep 1.6 support/testing as well) is impossible without additional help.
- The security updates that are being discontinued for Java 6 have a lot more to do with applets in the browser than with local applications like Processing. If we were supporting applets or JNLP-launched applications, it would definitely be a concern. Also, because we don't have an installer that places java.exe in a usable generic location on folks' machines, that means it shouldn't be possible to use Processing as an attack vector for Java-related attacks.
All that being said, we're putting a lot of effort into working toward supporting Java 7 because the writing is on the wall: we need to move to 7 eventually. The Experimental Mode work is part of that, and Manindra is doing some additional hacking based on what he learned there to help make the transition possible.