<div class="skinny">

<h1 class="ref-header" id="top"><img src="../images/changes_header.gif" alt="Changes.

changes are presented on this page." /></h1>

<p><a href="#used">This used to work and now it doesn't</a><br />

<a href="#0162">Changes in Processing 1.0</a> <br />

<a href="#0116">Changes in Beta 0116 (approaching 1.0)</a><br />

<a href="#0085">Changes between Alpha (Release 0069) and Beta (Release 0085)</a>

</p>

<h5 id="used"><a href="#top"><img src="../environment/images/up_arrow.gif" alt="Top" /></a> This used to work and now it doesn't</h5>

<p>For each release, read the revisions.txt file (included with the download) 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.

If you don't want to download first, you can read the most recent version

<a href="http://processing.org/download/revisions.txt">here</a>.

</p>

This page was updated prior to release 1.0.

<p>&nbsp;</p>

<h5 id="0162"><a href="#top"><img src="../environment/images/up_arrow.gif" alt="Top" /></a> Changes in Processing 1.0 (revision 0162)</h5>

The biggest changes in the months prior to release 1.0 are as follows:

<li><b>Libraries</b> - All libraries must be placed in a folder named "libraries", inside the sketchbook folder. Do not use the main "libraries" directory in the Processing distribution, as it is reserved for the core libraries, and is not visible on Mac OS X.

<li><b>XML</b> - The XML library is now included by default, so you won't find it in the Import Library menu anymore. In addition, the XML library since 0135 has been greatly improved, making it compatible with far more documents.

<li><b>Processing.app</b> - The Mac OS X release of Processing is now a single .app file, more befitting an OS X application.

<li><b>Processing.exe</b> - The Windows release has a new launcher based on <a href="http://launch4j.sourceforge.net/">launch4j</a>. Unfortunately, some machines <a href="http://dev.processing.org/bugs/show_bug.cgi?id=986">have a problem</a> with the new launcher that we haven't been able to track down. If you have trouble, please <a href="http://dev.processing.org/bugs/show_bug.cgi?id=986">help us find the problem</a>. PDE files are also now double-clickable on Windows.

<li><b>OpenGL</b> - All OpenGL sketches now use 2x full screen anti-aliasing. This means that these sketches are always smooth, and the smooth() and noSmooth() commands are ignored. To return to the behavior found in the beta releases, see the <a href="http://processing.org/reference/hint_.html">hint()</a> reference.

<li><b>P2D and P3D</b> - The P2D renderer has returned (see the <a href="http://processing.org/reference/size_.html">size()</a> reference) and smoothing is now enabled for both P2D and P3D. Smoothing support is unfortunately incomplete, however, and sometimes thin lines can be seen inside shapes. This is a very high priority <a href="http://dev.processing.org/bugs/show_bug.cgi?id=200">bug</a> to be fixed in a future release.

<li><b>Candy and PShape</b> - The Candy SVG library has been merged into the core, which brings along a new <a href="http://processing.org/reference/loadShape_.html">loadShape()</a> command and a new <a href="http://processing.org/reference/PShape.html">PShape</a> object. The special powers of PShape will be rolled out in future releases. For the time being, loadShape() works best with the default renderer (JAVA2D). Complex shapes will often appear jagged or not at all when rendered with <a href="http://dev.processing.org/bugs/show_bug.cgi?id=1053">P2D, P3D,</a> and <a href="http://dev.processing.org/bugs/show_bug.cgi?id=947">OPENGL</a>. We've also added better support for SVG files created with Inkscape.

<li><b>PVector</b> - We've added a new class called <a href="http://processing.org/reference/PVector.html">PVector</a>, which is a simple three-dimensional vector (also known as point or tuple) class. This is useful for storing point data, or operations on 3D points.

<li><b>Tools</b> - A new Tools API has been created for developers who want to contribute code that extends the Processing Development Environment in some fashion. Let your creativity flow with fantastical contributions like "Color Selector 2.0", "ROT13 Code Mangler", and "I Am Rich". Visit the <a href="http://dev.processing.org/tools/">developer page on tools</a> for more information. Similar to libraries, tools are installed in a folder of the same name within your sketchbook folder.

<li><b>Asynchronous Images</b> - Big JPEGs and small pipes? We've added a new <a href="http://processing.org/reference/requestImage_.html">requestImage()</a> method that loads an image in the background so that your sketch doesn't freeze when loading lots of large images over a slow connection.

<li><b>Sound</b> - We've added Damien Di Fede's <a href="http://code.compartmental.net/tools/minim/">Minim</a> library to the download. It uses the JavaSound API to provide an easy-to-use audio library. Minim has a simple API while still providing a reasonable amount of flexibility for more advanced users. Many thanks for Damien for his hard work on this excellent library.

<li><b>Present</b> - Present mode (full screen) is handled differentl in 1.0. When run inside the PDE, only Mac OS X uses full &ldquo;screen exclusive mode&rdquo; with Present. Windows and Linux just do full screen windows. When run outside the PDE, all three simply create an undecorated window the size of the entire screen, and on the Mac, an option is added to the Info.plist file to hide the dock and menubar (since that cannot be done programatically from inside Java applications).

<li><b>Compiler</b> - We've removed the old Jikes compiler and are now using the ECJ compiler from the Eclipse project. We've also tried hard to improve the quality of error messages, though some are still real gems that sound like error messages from mainframe computers in 1970s films. If you don't like the messages <a href="http://dev.processing.org/">please help us improve them</a>.

<li><b>Internationalization</b> - For better internationalization support, we've changed to UTF-8 encoding when loading and saving sketches. Sketches that contain non-ASCII characters and were saved with Processing 0140 and earlier may look strange when opened. Garbled text and odd characters may appear where umlauts, cedillas, and Japanese formerly lived. If this happens, use the "Fix Encoding & Reload" option under the Tools menu. This will reload your sketch using the same method as previous versions of Processing, at which point you can re-save it which will write a proper UTF-8 version.

<li><b>Java</b> - Linux and Windows now inlude Java 6 update 10 with the download. We still <a href="http://dev.processing.org/bugs/show_bug.cgi?id=598">don't have support</a> for Java 1.5 syntax yet, but we hope that the performance boosts in Java 6 will help applications run well.

Under the old numbering system, Processing 1.0 is revision 0162.

<p>&nbsp;</p>

<h5 id="0116"><a href="#top"><img src="../environment/images/up_arrow.gif" alt="Top" /></a> Changes in Beta 0116+ (approaching 1.0)</h5>

Release 0116 contains many changes, frameRate(), beginShape(),

and endShape() are the biggest ones.

<LI> framerate() is now called frameRate(), for better API consistency.

It didn't make sense to have a frameCount variable and a framerate()

method as its misshapen cousin.

<LI> The default frame rate is now 60 fps. This will prevent some odd

quirks with sketches running faster than they need to and throttling

the resources of your machine. To disable this, you can set the

frame rate arbitrarily high.

<LI> beginShape() has changed. LINE_LOOP and LINE_STRIP have been

removed because they are redundant, and not consistent with the

rest of the API. beginShape(POLYGON) is no longer recommended,

simply use beginShape() with no parameters when drawing an

irregular shape. Code examples:

OLD SYNTAX:

beginShape(POLYGON);

// call vertex() several times

endShape()

NEW SYNTAX:

beginShape();

// call vertex() several times

endShape(CLOSE);

endShape() with the CLOSE parameter will make the stroke on your

shape continue back to where the shape started. This is the same

way that POLYGON and LINE_LOOP worked.

OLD_SYNTAX:

beginShape(LINE_STRIP);

// draw with vertex()

endShape();

NEW SYNTAX:

noFill();

beginShape();

// draw with vertex();

endShape();

In the above case, noFill() must be called, and the CLOSE parameter

to endShape() is not used, because the last point should not come

back to meet the original point.

OLD SYNTAX:

beginShape(LINE_LOOP);

// draw with vertex()

endShape();

NEW SYNTAX:

noFill();

beginShape();

// draw with vertex();

endShape(CLOSE);

For the LINE_LOOP example, endShape(CLOSE) is used to specify close the

shape. noFill() must also be called, so that the shape is not filled in.

<br />

The two main problems with the old API were 1) LINE_LOOP was simply a

POLYGON with no fill setting, this made for a strange inconsistency.

2) there was no way to draw a non-closed POLYGON shape.

<br />

Using beginShape(POLYGON) doesn't make much sense when you're drawing

a line, so this is one more reason that beginShape() with no parameters

is recommended.

<LI> The single pixel blend() methods have been removed, they were

overkill. Also, the blend() function that blends a color, instead

of image data, is now called blendColor().

<LI> Along with blendColor(), a lerpColor() method has been added.

It works just like lerp()... but with colors!

<LI> writer() and reader() are now createWriter() and createReader().

<LI> toInt() and toFloat() are now parseInt() and parseFloat(),

to change to JavaScript syntax. Not sure if anyone was using these.

<LI> Text with the JAVA2D setting no longer uses native fonts by default,

which means they'll be slower and uglier. See the reference for

<A HREF="http://processing.org/reference/textFont_.html">textFont()</A>

for details and how it can be addressed.

<LI> Threading has been modified signficantly. Some of these changes

had to be undone at the last minute, so further changes are coming.

The changes will fix several strange InterruptedException problems.

<LI> The PGraphics classes have all been reworked and renamed.

<LI> PGraphics is an abstract class on which additional PGraphics

subclasses can be built. It is an abstract class, and therefore

cannot be invoked directly.

<LI> PGraphics2D (P2D) contains the former contents of PGraphics that

are specific to 2D rendering. This will be P2D once it is complete.

As of release 0126, P2D is not currently complete

and cannot be used.

<LI> PGraphics3D (P3D), formerly PGraphics3, remains mostly unchanged.

<LI> PGraphicsJava2D (JAVA2D), formerly PGraphics2, is the renderer

used when you call size(w, h) or size(w, h, JAVA2D). It remains

the default renderer when none is specified. It is slower but

more accurate than the others.

<LI> PGraphicsOpenGL (OPENGL) is the new name for PGraphicsGL.

<LI> Do not use "new PGraphics" to create PGraphics objects.

Instead, use createGraphics(), which will properly handle connecting

the new graphics object to its parent sketch, and will enable save()

to work properly. See the reference for <A HREF="http://processing.org/reference/createGraphics_.html">createGraphics</A>.

<LI> For the same reasons as above, createImage(width, height, format)

should be used instead of "new PImage" when <A HREF="http://processing.org/reference/createImage_.html">creating images</A>.

<LI> More recent releases include better support for ARGB format images.

This is helpful for using createImage() or createGraphics() to generate

a transparent surface. Be sure to use PNG or another format that

supports alpha. This support is incomplete, however, and there

are a handful of bugs.

<LI> beginFrame() and endFrame() are now beginDraw() and endDraw().

Use these around drawing commands to a PGraphics created by

createGraphics(). The defaults() method should not/need not

be called, just beginDraw() and endDraw().

<p>&nbsp;</p>

<h5 id="0085"><a href="#top"><img src="../environment/images/up_arrow.gif" alt="Top" /></a> Changes between Alpha (Release 0069) and Beta (Release 0085)</h5>

<p>Between revision 0069 (the last public alpha) and the beta release (0085),

many, many functions have been added, and are detailed in the

<a href="http://processing.org/reference/index_ext.html">complete

reference</a>. Aside from that, this page lists functions whose

names have changed or fundamental API differences between the

two versions.

<LI>loop() has been removed, and is instead called draw(). If you want

applications to only run draw() once (the way draw() used to work),

use the function noLoop() inside of setup().

<LI>size() should now be the very first thing in your setup(),

otherwise commands that come before it may be ignored. your settings for

fill() and stroke(), for instance, will disappear after you call size().

<LI>2D and 3D graphics are no longer completely mixed. To specify

3D graphics, instead of size(200, 200), the new way is to use

size(200, 200, P3D).

<LI>You may find that by default, your code runs more slowly in a beta release than an alpha release. The new renderers might be slower for some things, faster for others. If you want faster pixel operations, try using P3D (until P2D is available). For high-quality lines and strokeWeight() and strokeCap(), use JAVA2D (the default).

<LI>BImage &rarr; PImage, BFont &rarr; PFont, and so on...

<LI>For advanced users who were making their own BGraphics objects in

the previous release:

<PRE>BGraphics bg = new BGraphics(200, 200);

should be changed to:

<strike>PGraphics pg = new PGraphics2(200, 200, null);

pg.defaults(); // clear the buffer, get it ready</strike>

PGraphics pg = createGraphics(200, 200);

pg.beginDraw();

// drawing commands for pg here

pg.endDraw();

<strike>We didn't realize quite how many people were using this, so we'll probably

add a createGraphics() method because PGraphics2 may be temporary (instead

of just PGraphics), and the "null" thing is pretty weird. Even still,

this isn't quite working as expected, but it's a high priority to fix

for the future, see <NOBR><A

HREF="http://dev.processing.org/bugs/show_bug.cgi?id=92">Bug 92</A></NOBR>

for the status.</strike>

<LI>To use OpenGL rendering, change that to size(200, 200, OPENGL),

and use Sketch &rarr; Import Library &rarr; opengl. OpenGL support is

incomplete, but allows for much larger screen sizes and accelerated

graphics that make use of a decent graphics card.

<LI>When using the pixels[] array of the main window, or on an image,

you should first call loadPixels(). Once you're done editing, call

updatePixels(). This is because the new JAVA2D and OPENGL renderers both need to post-process the image data before displaying it, which is a time-consuming operation.

<LI>Library events are handled differently because more than one

serial port or video input device can be used with Processing

beta. See the documentation for

href="http://processing.org/reference/libraries/video/movieEvent_.html">movieEvent</a>,

href="http://processing.org/reference/libraries/video/captureEvent_.html">captureEvent</a>, and

href="http://processing.org/reference/libraries/serial/serialEvent_.html">serialEvent</a>.

Documentation for clientEvent and serverEvent for network will also

eventually be linked from <a

href="http://processing.org/reference/libraries/net/index.html">this page</a>.

<LI>push() &rarr; pushMatrix()

<LI>pop() &rarr; popMatrix()

<LI>textureMode(NORMAL_SPACE) &rarr; textureMode(NORMALIZED)

<LI>textureMode(IMAGE_SPACE) &rarr; textureMode(IMAGE)

<LI>textMode(ALIGN_LEFT) &rarr; textAlign(LEFT)

<LI>textMode(ALIGN_RIGHT) &rarr; textAlign(RIGHT)

<LI>textMode(ALIGN_CENTER) &rarr; textAlign(CENTER)

<LI>textSpace(SCREEN_SPACE) &rarr; textMode(SCREEN)

<LI>textSpace(OBJECT_SPACE) &rarr; textMode(MODEL)

<LI>font.width(String s) &rarr; textWidth(String s)

<LI>font.ascent() &rarr; textAscent()

<LI>font.descent() &rarr; textDescent()

<LI>Fonts should now be more accurately sized, if your font sizing looks weird, try using "Create Font" to create a new font using the most recent release of Processing. It's strongly suggested that you do this when updated projects from alpha to beta.

<LI>The function alpha(), when used to create an alpha mask of an image, is now <A HREF="../reference/PImage_mask_.html">mask()</A>, to remove a conflict with the alpha() function that extracts the alpha value of a color.

<LI>Previous default ellipseMode was CORNER &rarr; now it's ellipseMode(CENTER)

<LI>RGBA for images &rarr; ARGB (more technically accurate)

<LI>CENTER_DIAMETER &rarr; CENTER

<LI>objectX, objectY, objectZ &rarr; modelX, modelY, modelZ

<LI>curveSegments() &rarr; curveDetail()

<LI>bezierSegments() &rarr; bezierDetail()

<LI>splitStrings() &rarr; split() (changed in rev 0069)

<LI>splitInts() &rarr; toInt(split()) (changed in rev 0069)

<LI>splitFloats() &rarr; toFloat(split()) (changed in rev 0069)

<LI>angleMode() has been removed. Radians are used for all functions.

If you don't like radians, you can convert to radians to degrees via the radians() function, i.e.: sin(radians(90)).

<LI>Four calls to bezierVertex(x, y) should instead be a single call

to vertex(x, y), followed by bezierVertex(cx1, cy1, cx2, cy2, x2, y2)

(two control points followed by the destination point).

<LI>The libraries for serial, video, and network have changed

completely. Check out the examples or visit the <A HREF="../reference/libraries/index.html">libraries reference</A> for the full details.