OK, I'm brand new to this...

How do I create a box where the fill color blinks on and off? I'm trying to create a strobe effect. But, when I try to change the fill color after a delay in a loop, it only changes once after the loop has completed.

Mark

oh of course it works also without opengl

This is a hack, for sure, but seems to do the trick. There is a 16 ms delay in the running the loop so, I adjust the ms value for the delay  - 16 to achieve the hz that I need.

Code:

import processing.opengl.*;
int i = 0;
float m = millis();
int s = second();
int[] delay = { 0, 1000, 500, 333, 250, 200, 167, 143, 125, 111, 100, 91, 83, 77, 71, 67, 63, 59, 56, 53, 50 };

void setup() {
  size(800,800,OPENGL); 
  stroke(255);
  smooth();
}

boolean on=true;
void draw() {
  background(0);
//  if(frameCount% 0== 0) {
    if(on)
	fill(0);
    else
	fill(255);
    on = !on;
    delay(delay[12] - 16);
    i++;
    print(i + " : " + millis() + " : ");
    println(second());
//  }
  rect(1,1,800,800);
} 

That sounds like bad advice to me.  If you set the frameRate in setup Processing will do its best to comply with the requested rate and I'm fairly sure setting it every frame isn't going to make any difference whatsoever.  Fluctuations in framerate are usually caused when processor intensive activity is going on.  I'm not sure exactly how Processing handles this, but it's not likely that it simply 'changes' the frameRate; thereby necessitating your suggestion.  What's more likely is that it will continue to process every frame and things will slow down below the given frameRate (regardless of what it's set at).  At some point I suspect it will start dropping frames to try and keep up...  but once things calm down it will carry on at the originally set frameRate...  and that's why frameRate isn't reliable for accurate timing.

From what I've seen suggested elsewhere you're likely to need a separate thread and some Java to handle timing at such a small level.  Maybe do a search - this question has definitely come up before.  For instance this thread may be relevant.

When in doubt have a look at the documentation:

"[frameRate] Specifies the number of frames to be displayed every second. If the processor is not fast enough to maintain the specified rate, it will not be achieved."

So if you set the frameRate to 90 it will certainly try and hit 90fps as long as you're not asking it to process too much.  The higher you set the frameRate the less of a time buffer it has to process stuff and the more likely things get slowed down.  However I suspect at some point it will start jumping frames in order to try and keep up:  e.g. I've seen it suggested that you set frameRate(999) to get the fastest possible framerate.

One thing is certain though and that's that you can't use frameRate for reliably accurate timing... especially when making heavy demands on the processor.  To test it I guess you could log millis() to get some sense of how reliable it is and whether this meets your needs.