I'm having difficulty with the interplay between loop(), noLoop(), and redraw().

The program I'm writing mixes in the video library looking at the screen to do things like blob detection.  Part of this is a calibration step where I alternate filling the drawing with stripes, grab a camera frame and do some image processing to create a camera to screen transform.

I couldn't get the loop/noLoop/redraw interaction right, so I built the attached test.  It starts by looping through the gray colors (if the noLoop in setup is commented out).  Pressing any key sets the fillColor to Red, then Green, then Blue; calls redraw(), then pauses a second after each.

What happens on a key press is simply a pause, without the R/G/B backgrounds taking effect.  If I uncomment the noLoop in setup, it works the first time, but failes from then on.

So how is all this supposed to work?  Or am I going at this wrong, and there is an immediate drawing mode that I don't know about?  

As I understand it, the right Processing "pattern" is to do all your drawing only with draw(), using state variables to indicate what to draw.  This is due to the setup required each time through the draw(), thus the need for a redraw() which wraps the draw() with the proper code.

Thanks!

Owen

color fillColor = 0;
void setup() {
 size(600, 600, P2D);
 //noLoop(); // If uncommented, works first time, but then fails
}
void draw() {
 background(fillColor);
 fillColor = (fillColor + 1) % 256 ;
}
void keyPressed(){
 print("key pressed");
 color savedColor = fillColor;
 noLoop();
 fillTest(color(255,0,0));
 fillTest(color(0,255,0));
 fillTest(color(0,0,255));
 fillColor = savedColor;
 loop();
 println(" -- key done");
}
void fillTest(color c) {
 print(" . ");
 fillColor = c;
 redraw();
 delay(1000);
}

PhiLho: thanks, that helps, quite a bit.

It makes me realize that my real problem is the overall state machine used by Processing.

For example, within a draw(), I think all graphics is deferred until the draw() exits.  This optimizes the graphics setup overhead that would occur with immediate drawing.  Probably has a double buffering optimization as well.

Outside of draw(), it seems like there's an immediate mode graphics.

Yet a draw() is needed in order to process events.  Not sure why, I suspect its related to the thread architecture of Processing.

So what I *REALLY* need, it seems, is a pointer to a detailed description of the Processing state machine: how drawing, events, threads all work together and how the loop/noLoop/redraw -- and event management, and immediate graphics all integrate.

Whew!

Owen