Changes in 3.0
This document summarizes major changes in Processing between versions 2.0 and 3.0. If you are updating code from 1.x to 2.x, use this page.
The latest release of Processing is 4.0, and you can read about changes in 4.0 here.
This page lists the most important changes between Processing 3 for people who are familiar with Processing 2. For more specific details, read the revisions.txt file to see what's changed since the release before it. This is where you go if your code stops working in the most recent release, or if you want to know if your favorite bug has been fixed.
-
Rendering rebuilt - OpenGL (
P2D
andP3D
) is now stutter-free and very speedy. SomeJAVA2D
performance improvements as well. The newFX2D
renderer offers huge speedups for 2D drawing, especially with high density “retina” displays. -
New editor — The main editor window now includes:
- Autocomplete! (can be activated in Preferences)
- A full-featured, easy to use debugger
- Tweak Mode has been incorporated
-
New interface - the UI has received a major makeover.
-
High-res display support — New methods
pixelDensity()
anddisplayDensity()
make it easier to create sketches that will run nicely on high-res ("Retina") displays. It sounds so simple when put that way, but this is a really big deal. -
Unified Contributions Manager — We used to have separate windows for installing Libraries, Modes, and Tools. Now a single "Contributions Manager" helps you manage installation and updates for all of these contributions by third-party authors, plus... Examples!
-
Sketchbook Migration — If you already have a (2.x) sketchbook, 3.0 will ask if you want to create a new, 3.0-specific sketchbook, or share the existing one.
-
Do not use variables in
size()
- This time we really mean it. We've been saying thatsize()
must be the first line in setup since at least 2004, and that using variables instead of numbers will cause problems since 2006, and by at least 2009, simply "don't do it", but now the chickens have come home to roost. In the past, thesize()
function was implemented by doing backflips behind the scenes. Those backflips made things very fragile, introduced cross-platform quirks that have consumed too many of my weekends, and prevented us from making wholesale performance improvements to the rendering system (higher performance, better full screen support, etc). But despair not! If you must change the size of your sketch, usesurface.setSize(w, h)
which is the one and only (safe) way to alter your sketch's size. A short demo that's both resizable and gives you a random sketch window size whenever you hit a key:
void setup() {
size(400, 400);
surface.setResizable(true);
}
void draw() {
background(255);
line(100, 100, width-100, height-100);
}
void keyPressed() {
surface.setSize(round(random(200, 500)), round(random(200, 500)));
}
-
Applet is gone — Java's
java.awt.Applet
is no longer the base class used byPApplet
, so any sketches that make use of Applet-specific methods (or assume that aPApplet
is a Java AWTComponent
object) will need to be rewritten. -
You only smooth once —
smooth()
andnoSmooth()
can only be used insetup()
, and only once per sketch. Note thatsmooth()
has enabled by default since 2.x, so it's unlikely you'll need it anyway.
For the curious or insomniac, this document has the technical details about why these changes were made.
-
Use the
FX2D
renderer for greatly improved 2D graphics performance. It has many improvements over the default renderer, though it has a few rough edges so we haven't made it the default. -
fullScreen()
method makes it much easier to run sketches in, well, full-screen mode. -
The
PVector
class now supports chaining methods. -
SVG Export that works just like the PDF Export
-
A new
settings()
method that is called behind the scenes. Most users will never notice this, but if you're using Processing without its preprocessor (i.e. from Eclipse or a similar development environment), then put any calls tosize()
,fullScreen()
,smooth()
,noSmooth()
, andpixelDensity()
into that method. More information can be found in the reference. Only users who are in other development environments should usesettings()
. It shouldn't be used for any other purpose. -
Updated application icons.
- The Video and Sound libraries are no longer included in the download (because they've grown too large) and must be installed separately. Use Sketch → Import Library → Add Library... to install either one.
- The variables
displayWidth
anddisplayHeight
should not be used. They're still available in 3.0 so that less code breaks in the meantime, but that won't last forever.
- Lots of bugs
- There are plenty of issues and we could use some help!
- On Windows, launch4j doesn't work from folders with non-native charsets. On an English version of a Windows system, any characters in CP1252 are fine.
- When using
cursor()
in P2D and P3D, the cursor images do not match what you expect from the OS. - When using
selectInput()
,selectOutput()
, andselectFolder()
with OpenGL on Windows, the sketch window will close until the file is selected. We're waiting for an upstream fix from the JOGL project. - It's not really a 3.0 change, but Apple changed how key repeat works in macOS Sierra, which will break some projects. See here for details and how to fix it.
- If you have a lot of fonts installed, sketch startup time and initial
text()
rendering time can be extremely slow. This is due to an unfortunate Java bug and out of our control.
Some Libraries, and all Modes and Tools will need to be updated to be compatible with 3.0. If you've written one of these, thank you! and read on:
-
For the vast majority of authors, the changes are quite simple, and involve class name or package changes inside
processing.app
.- The exception is any Library where 1) assumptions were made about
PApplet
being a subclass ofApplet
(andComponent
), or 2) relied on AWT-specific features inprocessing.core
. More about the changes to core can be found here.
- The exception is any Library where 1) assumptions were made about
-
Modes and Tools need slight modifications because much of the UI code for Processing has moved from the
processing.app
package (which had grown unmanageably large) intoprocessing.app.ui
. This doesn't give us the perfect separate of UI and non-UI code that CS professors dream about, but it's a helpful step in the right direction. -
Several of the (static) utility functions from
Base
have moved into classes calledUtil
,Messages
, andPlatform
becauseBase
was getting enormous. (It still is enormous, but it's now a wee bit more reasonable.) Since enough other things are breaking in 3.0, we're not including accessors for the deprecated version of the functions, just making a clean break. Common changes will include:-
Base.isMacOS()
orBase.isWindows()
becomesPlatform.isMacOS()
andPlatform.isWindows()
(sensible, right?) -
Base.showWarning()
becomesMessages.showWarning()
-
Base.log()
becomesMessages.log()
- A good rule of thumb is that if there are platform-specific qualities to it, it's probably in
Platform
. If it's a message (whether a dialog box or a log file), it's probably inMessages
. And all those file utilities are in thatUtil
class.
-
-
Modes (and some Tools) will also need to be updated based on the major UI changes in 3.0. The default “Java” Mode is now completely separate from the rest of the code, so it's a decent model for understanding how to use the new
EditorButton
classes and similar. If your Mode subclassesJavaMode
, you'll want to check out how Android Mode does this and how it imports the necessary classes from the Java Mode, since they're no longer on the defaultCLASSPATH
. -
Each Tool is only initialized once (in 2.x, this happened repeatedly). This saves lots of time and memory. The
init()
method was changed to pass aBase
object instead ofEditor
, because it's necessary to callBase.getActiveEditor()
whenever a Tool'srun()
method is called. See the Tool Basics page for an example. -
The 2.0 and 3.0 lists of Libraries, Modes, and Tools are stored separately, so it's possible to maintain both versions, if you'd like to do so. (Though it should be noted that all active efforts are on 3.x) Users also have the ability to use separate sketchbooks for 2.x and 3.x versions of Processing, so they can have separate versions installed while the transition happens.
-
Library authors, now is the time to reduce your reliance on AWT! In 3.0, we've moved away from AWT in a big way (here's why). Any library features that require AWT should be treated with suspicion. Modes and Tools can still use AWT, but the OpenGL renderers (
P2D
andP3D
) and the upcomingFX2D
renderer don't use AWT at all.- This is one reason we built the
processing.event
classes in 2.x, and have been removing spurious AWT usage from the core API, documentation, and examples.) It's now been a couple years since we made those changes. - The other reason is that we can't rely on AWT features when targeting JavaScript or Android, so it was encouraging bad habits.
- This is one reason we built the