[Mac OS X 10.5.2, 0153 Beta]

I wrote this code for my students to demonstrate the HSB color mode,
unfortunately the output is buggy. (It will occasionally take a few runs
before the bug appears, so give it a few chances to fail!) If
colorMode(HSB, 360) is called in setup, sometimes it will not stick, and
the sketch runs in the default colorspace. It runs properly only if the
colorMode is set inside draw().

color frontColor, backColor;
int hueValue, compHueValue;

void setup() {
size(500, 500);
colorMode(HSB, 360);
frameRate(15);

hueValue = 0;
compHueValue = hueValue + 180;
smooth();
}

void draw() {
frontColor = color(hueValue, 359, 359);
backColor = color (compHueValue, 359, 359);
background(backColor);

fill(frontColor);
noStroke();
ellipse(width/2, height/2, 500, 500);

hueValue+=1;
if (hueValue == 360)
hueValue = 0;

compHueValue = hueValue + 180;
if (compHueValue >= 360)
compHueValue -= 360;
}

this is related to bug #726.

this applies to any function that sets drawing state inside setup(), such
as strokeWeight(), fill(), etc. the problem is caused by the same issue as
bug #726, but that gives a different error message, so the bug is being
kept separate for people searching the database.

*** Bug 836 has been marked as a duplicate of this bug. ***

*** Bug 858 has been marked as a duplicate of this bug. ***

Strangely, the bug doesn't occur on my machine even after thirty tries or so - MBP Intel (Core
Duo, *NOT* 2Duo), Tiger 10.4.11, Processing 0144 (default dl).
A very brief idea about the irregularity in the occurence of #767, #726 and duplicates :
could it be related to how the very first rendering is done by the JVM ? Let's suppose the setup()
is *for sure* executed before any rendering, may the virtual machine be initializing the drawing
routines and characteristics before all informations passed to it from the setup() are processed
(e.g. a parallel computation of the data in the draw() itself) that leads to a time depending
readiness of the different parts of the draw but independent in terms of completion as all the
routines should be ready at the end of the processes before the first rendering ?

exactly, it's just a threading issue. that resize events (both internal and
external), window updates, draw() calls, etc. all have to be coordinated.
on first draw, there's some setup that happens, so basically it's getting
confused about when that needs to happen.

it's more likely to show up on some machines than others. 64-bit machines,
linux especially and windows as well, seem to be badly affected, for instance.

*** Bug 871 has been marked as a duplicate of this bug. ***

fixed for release 0145.