Why does the Processing `fill()` with alpha never

Question

Let's say we have the following code:

void setup() {
    background(0);
    size(200, 200);
    fill(255);        
    rect(75, 75, 50, 50);
}  

void draw() {
    fill(0, 2);
    rect(0, 0, width, height);
}

Even after waiting 'forever,' the white 50x50 rectangle is still visible, albeit faded. Why doesn't the fill(0, 2) eventually cover this up?

I suppose this question is twofold:

• Why doesn't it eventually fade to black, as in why does drawing another dark rectangle on top of the white one not erase it eventually (I'm thinking along the lines of putting tinted windows over each other; eventually even the brightest light won't shine through), and
• Why doesn't it eventually fade to black, as in why is this the behavior intended by the Processing community?

Answer 1

The default background color is darker than the color you assigned to the first rectangle, thus it gets black sooner.

• Why doesn't it eventually fade to black, as in why does drawing another dark rectangle on top of the white one not erase it eventually (I'm thinking along the lines of putting tinted windows over each other; eventually even the brightest light won't shine through), and
• Why doesn't it eventually fade to black, as in why is this the behavior intended by the Processing community?

Also, in your original code (not the above sample) you're probably drawing the white rectangle continuously, so it will never fade.

Answer 2

Here's a post explaining what's going on: http://processing.org/discourse/beta/num_1138703939.html

Basically, the problem is that Processing stores colors as ints, but takes float arguments. When combining colors, Processing rounds the floats to ints. In your case, your color is getting stuck at a value of 63, 63, 63 because at that point the blending is too slight to make a difference that is detectable after rounding.

The solution is to do the fading from the source, not by overlaying an alpha color over top.