Background() causing weirdness with get()

Processing Coding Questions
1

I’m trying to use get() to make patterns using the previous frame, so I’m calling get() at the start of draw().

If I use background() after that to clear the frame, I find that what get() has given me is not the previous frame but the frame before that.

I’ve made a simple 2D sketch that shows the issue. It draws alternating green and blue circles along the bottom of the window. When I use background() I see alternating frames of all green or all blue circles:

ProcessingBackground !

However, if I remove background() and just draw a rect() the same size as the screen, which I would think should be equivalent to using background() in this sketch, I find that get() has given me the previous frame as intended and I get a mixture of green and blue circles.

The grey circles I tried adding before get() to see what would happen. They appear in the right place, but if background() is used they’re drawn on top of the wrong frame.

What’s going on here?

Here’s my code

PImage getWindow;

void setup() {
  size(400, 300, P3D);
  frameRate(2);
}

void draw() {

  fill(150);
  ellipse( 40 + (width / 5) * (frameCount % 5), 270, 50, 50);

  getWindow = get();

  //remove this to see the difference
  background(128);

  fill(128);
  rect(0, 0, width, height);

  fill( 0, 255 * ((frameCount + 1) % 2), 255 * (frameCount % 2));
  ellipse( 40 + (width / 5) * (frameCount % 5), 270, 50, 50);

  beginShape();
  texture(getWindow);
  vertex( 50, 10, 0, 0, 0);
  vertex( 350, 10, 0, width, 0);
  vertex( 350, 235, 0, width, height);
  vertex( 50, 235, 0, 0, height);
  endShape(CLOSE);
}
2

Here’s what it looks like with rect() rather than background:

ProcessingRect

3

Why don‘t you just get the Image as the last Part of draw? It Would still save the Image to getWindow, But Would make it easier to See what is Happening without having to think about which Frame you see.

4

Thanks, that does produce the right result, though I still don’t understand why.

5

Well, trying to get something from the last Frame in the Next Frame will have to happen after draw is called, which means there were a lot of things happening between the last Frame and the Start of your code in the new Frame. There might be something that Messed with your code in between there, that is avoided by just doing it last in the previous Frame. Try to always keep everything in the Same Frame.

6

That isn’t what is happening. You have a very complex sketch model that makes it difficult to test what is going wrong, and difficult to explain / understand.

Start with something really really simple, like this:

void setup() {
  size(400, 300, P3D);
  noLoop();
}
void draw() {
  fill(255, 0, 0);
  ellipse( width/2, height/2, 100, 100);
  fill(128);
  rect(0, 0, width, height);
}

This sketch draws a red ellipse, then covers it with a grey rectangle. What happens? Is it what you expected? Why is this happening?

size(400, 300, P3D);  // <---- 3D ????

…what happens when you draw multiple 2D objects at the same depth in 3D space?

Try changing “P3D” to “P2D”.

7

I had kindof forgotten that I was using P3D, but I get the same results for my sketch in P2D.

PImage getWindow;

void setup() {
    size(400, 300, P2D);
    frameRate(2);
}

void draw(){
  
  fill(150);
  ellipse( 40 + (width / 5) * (frameCount % 5) , 270, 50, 50);
  
  getWindow = get();
  
  //remove this to see the difference
  background(128);
  
  fill(128);
  rect(0,0, width, height);
   
  fill( 0, 255 * ((frameCount + 1) % 2), 255 * (frameCount % 2));
  ellipse( 40 + (width / 5) * (frameCount % 5) , 270, 50, 50);
  
  image(getWindow, 50, 10, 300, 225);
  
}
8

With the last code you posted, I’m not seeing a difference when I comment out “remove this to see a difference.” The two sketches look the same.

55%20AM
Screen Shot 2018-11-02 at 8.53.55 AM.jpg1594×638 81.7 KB

9

The difference is definitely there for me when I specify P2D, but I just tried both leaving it unspecified and also FX2D, both of which displayed correctly (blue and green together as per your screenshot).

I’m using 3.4 if that makes a difference.

This isn’t a problem for me at this stage, since I’ve worked around it in the 3D sketch where I first encountered it, but I’m still mystified as what was going on.

10

Strange – I can’t reproduce that on Processing 3.4 macOS 10.12, but it could be something to do with OpenGL. I can explain what is going on in P3D – background and rect operate differently in 3D space. If you don’t need 3D, just use default / Java2D – otherwise you can use depth, blendmode, or hints to prevent counter-intuitive layer composition or “z-fighting.”

1 Like
11

Thanks for reporting, this is indeed a rare bug in Processing which is hard to reproduce.

I managed to reproduce it on Windows 10 1803, but only on Intel GPU, Nvidia works fine.

I filled an issue on GitHub and we will see what can be done: https://github.com/processing/processing/issues/5694

2 Likes