Bug 767 : fill(), stroke(), strokeWeight(), colorMode(), smooth() and others set inside setup() sometimes not set once draw() arrives
Last modified: 2008-08-15 07:08



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2008-05-06 05:26
[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);

hueValue = 0;
compHueValue = hueValue + 180;

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

ellipse(width/2, height/2, 500, 500);

if (hueValue == 360)
hueValue = 0;

compHueValue = hueValue + 180;
if (compHueValue >= 360)
compHueValue -= 360;
Additional Comment #1 From fry 2008-05-06 05:26
this is related to bug #726.
Additional Comment #2 From fry 2008-06-27 15:14
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.
Additional Comment #3 From fry 2008-06-27 15:15
*** Bug 836 has been marked as a duplicate of this bug. ***
Additional Comment #4 From fry 2008-07-24 20:47
*** Bug 858 has been marked as a duplicate of this bug. ***
Additional Comment #5 From AlexisChazard 2008-08-11 07:51
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 ?
Additional Comment #6 From fry 2008-08-11 08:11
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.
Additional Comment #7 From fry 2008-08-11 12:07
*** Bug 871 has been marked as a duplicate of this bug. ***
Additional Comment #8 From fry 2008-08-15 07:08
fixed for release 0145.