Gradual fading by re-drawing a transparent rectangle

Question

This is a question about Processing.org .

I clean up the previously created objects by drawing a translucent white rectangle above the view for each frame.

However, it seems they never fade to completely white. Attenuation has a fixed point in some noticeably non-white shade of gray. The same thing happens when you try to fade to black.

Is this a standard feature of alpha blending in processing? Is there a relatively easy way to get around it in order to achieve a completely white background (provided sufficient steps are taken)?

I assumed that the resulting color would be a linear combination of colors that mix, which means the limit should be white. Perhaps a non-white fixed point is a rounding artifact?

Sample code illustrating the problem:

void setup() { size(300,300); background(0); noStroke(); frameRate(15); } void draw() { fill(255,10); rect(0,0,width,height); fill(255); rect(0,0,50,50); // for comparison to white } 

edit: added java tag in the hope of more attention

Answer 1

I'm not sure what is happening, it looks like you should be right, and if the number of rectangles drawn *, the alpha value of these rectangles is more than 255, it should be completely white. In any case, why not just redraw every frame (for example, I move the background line (0) into the drawing loop) and then just increase the alpha value. I think this way will give you more control over the animation in the future.

 int a; void setup() { size(300,300); noStroke(); frameRate(15); a = 0; } void draw() { background(0); a += 1; if(a<=255){ fill(255,a); } rect(0,0,width,height); fill(255); rect(0,0,50,50); // for comparison to white } 

Answer 2

I rummaged a lot, and now I'm sure that the complete disappearance of the alpha channel is impossible. However, there is a thing called brightness, so let's use it.

 void setup() { size(300,300); background(0); noStroke(); frameRate(15); // White rectangle for fading comparison. fill(255); rect(0, 0, 50, 50); } void draw() { fade(10); } void fade(final int fadeSpeed) { loadPixels(); for (int row = 0; row < height; row++) { for (int col = 0; col < width; col++) { final int pixelIndex = row * width + col; int pixel = pixels[pixelIndex]; int red = ((pixel >>> 16) & 0xFF) + fadeSpeed; int green = ((pixel >>> 8) & 0xFF) + fadeSpeed; int blue = (pixel & 0xFF) + fadeSpeed; if (red > 255) { red = 255; } if (green > 255) { green = 255; } if (blue > 255) { blue = 255; } // Shift bits back into propper position and red <<= 16; green <<= 8; pixel &= 0xFF000000; // Keep alpha bits. pixel |= red |= green |= blue; pixels[pixelIndex] = color(pixel); } } updatePixels(); } 

By increasing all three color channels (red, green, blue), we do not change the color, but the brightness.

Answer 3

I found that although the rounding error (if that's what it is) applies to everything you can try using blendMode(SUBTRACT) and then filling with a very small color in shades of gray (like fill(2) ) reaches gradually disappear in many draw() cycles without a “ghost” image, which apparently has all the other approaches, while the frame rate increases (which is often critical in real-time drawing situations).

  // The only reasonable way to actually "fade" out the pixels. blendMode(SUBTRACT); fill(2); rect(0, 0, width, height); blendMode(NORMAL);