Processing: Creative Coding and Computational Art

PROCESSING: CREATIVE CODING AND COMPUTATIONAL ART
484
In the previous Java example, notice that I explicitly instantiate a Thread object:
Thread t = new Thread(this);
A few lines later, in the run() method, notice the following block:
try {
Thread.sleep(30);
}
catch (InterruptedException e){
}
The run() method continuously executes, which is where the drawing happens, and the
Thread.sleep(30) call adds a delay between each execution (or frame); the larger
the delay value, the slower the animation. Finally, I also needed to call the command
repaint(), which forces the screen to be updated each frame—allowing you to see the
animation. Whew! That’s a lot to deal with. Fortunately, you don’t need to worry about
most of this stuff in Processing.
In the Processing example, notice the draw() function. This Processing function encapsulates
most of the annoying stuff involved in creating animations with threads in the Java
example. Simply including the draw() function in your sketch causes a thread to begin
running (under the hood).
In the last two examples, the actual animation involved a rectangle moving across the
screen. If it wasn’t obvious, the variable x was incremented by xspd each frame, and then
the rectangle was drawn with the updated x value. In a sense, I simply redrew the rectangle
over and over again, at a different x position. The reason you don’t see all the previous
drawn rectangles is because of the call background(255); at the top of the draw() function.
This call fills the screen with white between each frame, painting over the previous
rectangle. This repainting of the background between draw frames is what gives the
illusion that a single rectangle is moving across the screen. Try commenting out
background(255); in the last sketch and rerunning it (see Figure 11-1).
Figure 11-1. Sketch with background() commented out