Skip to content

Supported Platforms

Jump to bottom
Ben Fry edited this page Aug 5, 2022 · 13 revisions

This page describes how Processing works on the different platforms we support across macOS, Windows, and Linux. Scroll to the bottom, and you can even read about different versions of Java.

The Processing Development Environment (PDE) is currently tested on:

  1. macOS 10.15.7 (Catalina), 11 (Big Sur), and 12 (Monterey) on Intel hardware – Apple is upgrading once a year, we are forced to chase them. Major OS releases are supported by Apple for just 3 years, and we shouldn't (can't, for lack of time) be extending beyond that. Note that we only support the most recent point release for older versions. So get those Catalina machines upgraded to 10.15.7!
  2. macOS 12 (Monterey) on Apple Silicon – We're now shipping an Apple Silicon version as of 4.0 beta 8!
  3. Windows 10 (64-bit Intel) – support for Windows 7 ended in 2018. Most people would like to forget about Windows 8. We are not currently (as of 5 August 2022) testing on Windows 11 and therefore cannot exactly recommend it, but it should work fine.
  4. Linux (Ubuntu 22.04, 64-bit Intel) – If you're using a different Linux, please help us make improvements so that it runs on your platform of choice. We just can't do everything.
  5. Linux on Raspberry Pi (32-bit ARM) – We don't currently have a maintainer, but we're doing releases. This is the only 32-bit platform that is supported with Processing 4.
  6. Linux on Raspberry Pi (64-bit ARM) – Not a ton of people are 64-bit with their RPi devices yet, but it's happening.

If something is broken on one of those platforms, we'll try to fix it. Most of the cross-platform work is done from a certain developer's laptop that has seven or eight VMware images to deal with all this mess. As of August 2022, that developer spends most of their time using macOS on Apple Silicon, followed by macOS on Intel and several Linux linux versions across ARM and Intel. Windows, not so much.

Things that can't be tested from a VM are run from machines at the Processing Release Testing And Quality Assurance Center (the PRTAQAC, which is currently a number of machines laying about Fathom's studio).

Also check out the Troubleshooting page for platform-specific issues.

Windows

Windows has traditionally been the best/most supported platform for running Java applications. Nowadays, there's more parity between Windows, macOS, and Linux releases.

macOS

Apple has aggressively updated their OS and deprecated old features. Older versions of Processing (3.x and earlier) are likely to not work at all, due to Apple's updates and restrictions. Please use 4.0!

  • The key conventions in Processing are closer to other programmer's editors on macOS (BBEdit, Eclipse, etc) than other macOS defaults. 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 this is not to your liking, 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

Retina Support

For Processing 3, use the pixelDensity() command to enable super-crisp rendering on retina displays. See here for the reference.

Linux

With any luck, the Linux release should work fine by simply changing to the processing folder and typing

 ./processing

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 JRE 8. You can also symlink it to a JRE 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.

If you replace the 'java' folder, you'll lose the default fonts used for the PDE. You can get them back by copying the “SourceCode” items from the included java/lib/fonts folder to your new java/lib/fonts. This is no longer the case in releases later than Processing 3.2.1.

Due to incompatibilities, OpenJDK is not supported. You'll need a regular Java release downloaded from 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.

Information on how to install Java from Oracle on Ubuntu can be found here: https://help.ubuntu.com/community/Java.

If you get Processing to run properly, the Sketch → Show Sketch Folder command may not be available. Processing will attempt to find xdg-, kde-, and gnome-open, and if none 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

To install on Ubuntu Linux 14.04:

  • Download the latest installation (processing-3.2.1-linux64.tgz, for example)
  • Open a terminal
  • Copy the installation to your home folder
  • Extract using: tar zxf processing-3.2.1-linux64.tgz
  • Run using ~/processing-3.2.1/processing
  • The splash screen and application should now be displayed

To add an Ubuntu launcher icon:

  • Run as above
  • Select the icon in the launcher
  • Right click and select 'Dock to Launcher'
  • Close the application
  • Open a terminal
  • Run 'vim ~/.local/share/applications/processing.desktop' (or use 'nano' in the place of 'vim')
  • Use the following lines to replace the existing ones, with your login name in the place of 'mylogin'
    Icon=/home/mylogin/processing-3.2.1/lib/icons/pde-48.png
    Path=/home/mylogin/processing-3.2.1
    Exec=/home/mylogin/processing-3.2.1/processing

ARM Linux

Devices

For new devices, please start a new page:

FX2D

The experimental FX2D renderer is not supported on ARM, because Oracle dropped support for JavaFX on ARM devices with Java 8u33. We might want to try using OpenJFX project in the future, but as of now this is unsupported.

Libraries

Most libraries from the Contribution Manager work just fine without any change necessary to run on ARM. Exception to this are libraries that comes with parts written in "native code", which is platform- and architecture-dependent, and hence needs updating. As a general rule of thumb: if you find (sub-) directories for different platforms inside the library's library directory, then this is likely the case.

If you come across a library that's not working, or if you need help compiling a library for ARM, please open an issue.

Library: OpenCV

ARM devices are supported by Greg Borenstein's OpenCV library starting with version 0.5.4 (available in the Contribution Manager).

Library: OpenKinect

A test version of Open Kinect for Processing, with support for armv6hf, can be found here. (PR #1 #2) On most ARM devices this will only work (if at all) with the Kinect 1, because of the high demand on USB throughput of the Kinect 2. Don't forget to place the file 51-kinect.rules in /etc/udev/rules.d for Processing to be able to access the Kinect's camera.

Library: PureData

The puredatap5 library allows you to write sketches in Processing that control and interact with musical patches prepared in Pure Data. See the accompanying HelloPd example for how it works. This library requires PortAudio to be installed, which seems to be the case for current releases of the Raspbian distribution. This library is not yet available through the Contribution Manager, but support for ARM was merged into its main repository.

Library: Processing Sound

ARM devices are supported by Processing's Sound library starting with version 1.4.0 (available in the Contribution Manager).

Library: Simple Touch

The simpletouch library makes it possible to use any multi-touch-enabled display or trackpad with Processing, as long as the device is supported by the Linux kernel. This library is available through the Contribution Manager under the name "Simple Touch".

Two example sketches the library comes with explain how to use it. Please file issues here.

OpenJDK

Processing is designed (and supported) to run on Oracle Java. The tar-ball comes with a recent version of Oracle's runtime for hard-float ARMv6 (and higher) architectures.

Other Platforms

Because Processing is written in Java, it should run on any platform that supports Java 8. If you'd like to get it running on BSD, Irix, AmigaOS, BeOS... whatever, do the following:

  1. 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).
  2. Next, mess with the shell script if necessary to get things up and running.
  3. If you have success, share the details for others.

OpenBSD

Users of OpenBSD can use the ports and packages framework to install Processing using the following command:

pkg_add processing

Please note this package is not created by the Processing team and any possible issues should initially be reported to the package maintainer.

Java Versions

It's never necessary to install Java to use Processing. Across all platforms, Processing uses its own copy of Java that's embedded inside the application.

We don't yet support any of the Java 7 and Java 8 language features. Please help us fix this. Advanced users (loosely defined as “people who know that these features exist”) can always make use of Java 7 and 8 features from another IDE.

People often reinstall Java when they have problems with Processing. Even though it may make you feel better, reinstalling won't help anything, because Java doesn't need to be installed in the first place.

Java 8

Processing 3 uses Java 8 (but again, does not support all Java 8 language features). We only support the version of Java 8 that's included with the download. Because Oracle sometimes removes older updates, Processing will usually ship with the most recent update of Java 8 that was available at release time.

Java 9, 10, and 11

It's not possible to use Processing 3.x with Java 9 or later, due to several internal changes that break Processing libraries or the PDE itself. Java 9+ includes major changes to how the VM interacts with the OS, particularly on macOS. It requires rewriting and testing some fundamental code (how files are opened, how some menus work), and will take some time. There is no estimated date for when this work will be done.

We've skipped Java 9 and 10, but are working on Java 11 support in a new repository for Processing 4 with some major contributions from Sam Pottinger. Thanks Sam!

4.0 beta 4 includes several updates to how different operating systems and hardware are handled. This allows us to add Apple Silicon (M1) support, and also better handles other devices like the Raspberry Pi.

The final decision is that a “variant” should consist of the OS name (windows, macos, or linux) followed by a the naming from the os.arch value returned by System.getProperty(). Because those names can vary across JDK implementations, we'll be using the name used by the JDK included with the Processing download, which is currently from Adoptium.

This {name}-{arch} naming style helps drastically simplify the code inside the PDE, and also gets us out of the business of deciding how to rename each platform. While the naming is sometimes awkward (i.e. macos-x86_64), the alternatives are inelegant as well, so we'll err on the side of simplicity by inheriting how the platform handles naming. Users will (should) never see those awkward names! And only Library developers that need additional native code will need to understand the naming, but they should already be somewhat familiar with that nomenclature if they're working with native code.

As a result of these changes, the subfolders used to identify native libraries for each platform are different. Any library that used the old naming convention (macosx, windows64, etc) correctly will still work. But use these new names so that your library is ready for other platforms like Apple Silicon, or ARM on the Raspberry Pi.

Hardware/OS os.arch bits 4.0 library folder old library folder download suffix
macOS (Intel 64-bit) aarch64 64 macos-aarch64 — macos-aarch64
macOS (Apple Silicon) x86_64 64 macos-x86_64 macosx macos-x64
Windows (Intel 64-bit) amd64 64 windows-amd64 windows64 windows-x64
Linux (Intel 64-bit) amd64 64 linux-amd64 linux64 linux-x64
Linux (Raspberry Pi 32-bit) arm 32 linux-arm linux-armv6hf linux-arm32
Linux (Raspberry Pi 64-bit) aarch64 64 linux-aarch64 linux-arm64 linux-arm64

(The “bits” column is equivalent to sun.arch.data.model)

Technically, the Raspberry Pi releases may run on other ARM Linux installations, but they aren't tested that way. And the Raspberry Pi version includes additional libraries that are specific to the Pi. Put another way, generic Linux on ARM is not a supported platform, so we don't list it as “Linux (ARM 32-bit)” in places like Export to Application.

Some libraries did not properly use the old naming system, which will cause them to break in the 4.0 release. For instance, if dylib and dll files were simply placed in the root of a library, the library will probably not work. Moving the files into subfolders that use the naming conventions above should get them working again. If this sounds confusing, just look at how the core folder is laid out in the Processing software itself: it's a single library with native libraries for all six platforms to support OpenGL .

You can also view the Supported Platforms from 3.x, though half that information will be out of date.

Clone this wiki locally