Hello my knowledgeable new friends!

I am attempting a VERY simple program; a simple "strobe" (which I will be expanding to be a more interactive/dynamic program for a projection/VJ kinda thing).  However I'm having an issue with a foundational aspect - maybe you could help? (Code below...)

The applet simply creates a certain sized screen, then changes the background from black to white at a certain rate. The PROBLEM is that the resulting blink is not regular like a strobe, but is JERKY and annoying.

Yes, I have tried closing all the other programs running, and, no, the tiny li'l applet does not seem to ever use more than about 30% of my CPU.  The screen refresh rate is 60Hz, and I am trying to get a blink of 10Hz. Thus, the slightly awkward timing; 33ms white, 67ms black.

I guess this is more of a system-integration problem (using MacBook OSX 10.4.something w/ Intel chip.) than a code problem. Maybe. Here's the code.
---------------------------------

color c1 = #000000;
int i = 0;

void setup(){
  size (1250,750);}

void draw(){
if(i == 0){
   c1 = #000000;
   i = 1;
   delay(67);}
else{
   c1 = #FFFFFF;
   i = 0;
   delay(33);}
background(c1);}

-------------------------------
THANKS!

hmm, i thought of something like this :

void setup(){
size(300,300);
}

int strobeSpeed = 3;
void draw(){
background(0);
if(frameCount%strobeSpeed==0)background(255);

}



it kinda works, but its not a steady blinking as i expected it to be...
Any Idea, why that is PhiLho ?

Sorry, I looked too fast and was disoriented by your way of placing closing braces. The delays do not accumulate, actually.
The sketch is OK (can be improved, but functional) after all.
The issue is more in the way Java draws the image: it does that immediately, regardless of screen state.
It would be better if it was synchronized on screen refresh rate (some games are able to detect when monitor restart a screen sweep), although I don't know if it applies to LCD screens (I have a CRT one).
I tried to use OpenGL (parameter of size()), it is slightly better but not perfect.

Nice PhiLho -

We both honed in on defining frameRate independently - must be something there. I don't think LCDs have a screen sweep - the pixels simply stay at the state they are in until they are told to change. The refresh rate is the rate that the CPU communicates those changes to them. I guess this is in large part a problem unique to each computer in which the code is executed...

I'll try to work on making my code more canonical. Thanks...

For LCD display there are three Hz at play, other than the Hz defined in the code.

1. Is the rate at which the CPU communicates changed to the screen.
2. Is the blinking of the light behind the screen that the LCD pixels filter - this is usually very high, maybe 600Hz.
3. Is not really Hz, but is the response time of the pixels, the time it takes for them to change from open to closed, perhaps about 10 milliseconds.

The only other time than may have to be factored in is, 1; the time it takes for the CPU to process the code (short though it is) and  2; convert the data into instructions for the screen. Not sure of the architecture of this process, but the activity monitor reports this applet using about 20-30% of the CPU. Most of that must be #2.

I am not sure whether this trouble with creating a consistent strobe is due to mismatching Hz in the display, or whether the CPU cannot prepare the data quickly enough. My guess is the first, as making a very small screen size (which would reduce the information sent to the screen) does not rectify the problem.

OK. Now everyone can laugh at my poor understanding of how computers actually work... I'm laughing at myself... But it's obvious to me that this issue goes beyond writing code.