processing.core
Class PApplet

java.lang.Object
  java.awt.Component
      java.awt.Container
          java.awt.Panel
              java.applet.Applet
                  processing.core.PApplet

All Implemented Interfaces:

java.awt.event.FocusListener, java.awt.event.KeyListener, java.awt.event.MouseListener, java.awt.event.MouseMotionListener, java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable, java.lang.Runnable, java.util.EventListener, javax.accessibility.Accessible, PConstants

Direct Known Subclasses:

ColorSelector.ColorRange, ColorSelector.ColorSlider

public class PApplet
extends java.applet.Applet
implements PConstants, java.lang.Runnable, java.awt.event.MouseListener, java.awt.event.MouseMotionListener, java.awt.event.KeyListener, java.awt.event.FocusListener

Base class for all sketches that use processing.core.

Note that you should not use AWT or Swing components inside a Processing applet. The surface is made to automatically update itself, and will cause problems with redraw of components drawn above it. If you'd like to integrate other Java components, see below.

As of release 0145, Processing uses active mode rendering in all cases. All animation tasks happen on the "Processing Animation Thread". The setup() and draw() methods are handled by that thread, and events (like mouse movement and key presses, which are fired by the event dispatch thread or EDT) are queued to be (safely) handled at the end of draw(). For code that needs to run on the EDT, use SwingUtilities.invokeLater(). When doing so, be careful to synchronize between that code (since invokeLater() will make your code run from the EDT) and the Processing animation thread. Use of a callback function or the registerXxx() methods in PApplet can help ensure that your code doesn't do something naughty.

As of release 0136 of Processing, we have discontinued support for versions of Java prior to 1.5. We don't have enough people to support it, and for a project of our size, we should be focusing on the future, rather than working around legacy Java code. In addition, Java 1.5 gives us access to better timing facilities which will improve the steadiness of animation.

This class extends Applet instead of JApplet because 1) historically, we supported Java 1.1, which does not include Swing (without an additional, sizable, download), and 2) Swing is a bloated piece of crap. A Processing applet is a heavyweight AWT component, and can be used the same as any other AWT component, with or without Swing.

Similarly, Processing runs in a Frame and not a JFrame. However, there's nothing to prevent you from embedding a PApplet into a JFrame, it's just that the base version uses a regular AWT frame because there's simply no need for swing in that context. If people want to use Swing, they can embed themselves as they wish.

It is possible to use PApplet, along with core.jar in other projects. In addition to enabling you to use Java 1.5+ features with your sketch, this also allows you to embed a Processing drawing area into another Java application. This means you can use standard GUI controls with a Processing sketch. Because AWT and Swing GUI components cannot be used on top of a PApplet, you can instead embed the PApplet inside another GUI the way you would any other Component.

Because the default animation thread will run at 60 frames per second, an embedded PApplet can make the parent sluggish. You can use frameRate() to make it update less often, or you can use noLoop() and loop() to disable and then re-enable looping. If you want to only update the sketch intermittently, use noLoop() inside setup(), and redraw() whenever the screen needs to be updated once (or loop() to re-enable the animation thread). The following example embeds a sketch and also uses the noLoop() and redraw() methods. You need not use noLoop() and redraw() when embedding if you want your application to animate continuously.

 public class ExampleFrame extends Frame {

     public ExampleFrame() {
         super("Embedded PApplet");

         setLayout(new BorderLayout());
         PApplet embed = new Embedded();
         add(embed, BorderLayout.CENTER);

         // important to call this whenever embedding a PApplet.
         // It ensures that the animation thread is started and
         // that other internal variables are properly set.
         embed.init();
     }
 }

 public class Embedded extends PApplet {

     public void setup() {
         // original setup code here ...
         size(400, 400);

         // prevent thread from starving everything else
         noLoop();
     }

     public void draw() {
         // drawing code goes here
     }

     public void mousePressed() {
         // do something based on mouse movement

         // update the screen (run draw once)
         redraw();
     }
 }
 

Processing on multiple displays

I was asked about Processing with multiple displays, and for lack of a better place to document it, things will go here.

You can address both screens by making a window the width of both, and the height of the maximum of both screens. In this case, do not use present mode, because that's exclusive to one screen. Basically it'll give you a PApplet that spans both screens. If using one half to control and the other half for graphics, you'd just have to put the 'live' stuff on one half of the canvas, the control stuff on the other. This works better in windows because on the mac we can't get rid of the menu bar unless it's running in present mode.

For more control, you need to write straight java code that uses p5. You can create two windows, that are shown on two separate screens, that have their own PApplet. this is just one of the tradeoffs of one of the things that we don't support in p5 from within the environment itself (we must draw the line somewhere), because of how messy it would get to start talking about multiple screens. It's also not that tough to do by hand w/ some Java code.

See Also:

Serialized Form