Is this a known bug?

Puddle

I am currently working on an assignment for my school and I am running into a problem I can not seem to solve.

As this is a graded problem I would like to ask not to give me a solution but just to point out what could be causing this or if it's a known bug.

I am coding a program that needs to draw some content. The drawing is managed by a function that is invoked at the mouseClicked event.

Before the screen is drawn, the entire screen is refreshed within the called function using background(255).

The thing I am running into is that from time to time text content is placed on top of old content or lines are drawn towards the point that make up the starting point from where the text is drawn.

It does not produce this problem every time the program runs nor are any variables used that could effect the logic behind what is happening. Most annoying is that I can not seem to reproduce it myself. Going through the application the exact same way twice could one time produce this issue and the other time everything goes fine.

Any suggestions into what could be causing this would be great.

GoToLoop

• Maybe replace mouseClicked() w/ mouseReleased()?
• Also notice that all events are run after draw() is finished, as many times they were triggered.
• After all events have finished, the canvas' current content is finally rendered to the window.

Puddle

The entire draw() function is empty and is just there because it is required if I wish to use any events. So this could not be causing any issues as far as I am aware.

I just tried changing the type of event to a mouseReleased event but this seems to trigger the same weird behavior as the mouseClicked event.

All drawing to the screen is handled from the one function I mentioned that is invoked by the mouseClick event. This function in it's turn calls a few other functions that take care of a part of the complete output that needs to be send to the screen.

Could it be that some of these smaller functions that are invoked by the function that manages what is placed on the screen run in parallel and that this messes it up?

jeremydouglass

If draw is empty rather than including background, and if sometimes your background doesn't run....

Then the most likely explanation is that you have a conditional structure that only sometimes calls background.

This would be much easier to help you diagnose if you shared an MCVE.

Puddle

Hope this might help a bit. As mentioned draw() is completely empty. One of the problems seems that the rectangle in drawMenu get a with that is width / 2 and a height that is height / 2 sometimes out of the blue and other times it does not. Might also be that the origin from where the rect is drawn changes.... I have no idea. However it is not done by me in that case.

draw() {}

void mouseClicked() {
  //decides if screen needs to be redrawn if so
  drawScreen();
}

void drawScreen() {
  // SOME VARIABLES ARE SET

  background(255);
  drawMenu();

  for (int i = 0; i < int(sqrt(xxx.length)); i++) {
    for (int j = 0; j < int(sqrt(xxx.length)); j++) {
      //Invokes a function that uses some variables
      invokeFunction();
    }
   // Alter some variables
  }
}
void drawMenu() {
  fill(0);
  textAlign(LEFT, TOP);
  // Draw some text
  if (something) {
    // Thise text
  } else {
    t// This text
  }
  fill(#e3e3e3);
  rect(0, height, width, -(2 * value));
  fill(0);
  textAlign(CENTER, CENTER);
  // Write some more text
}

GoToLoop

• Seems like your sketch's rendering is event-driven.
• For that modality, you should call noLoop() in setup().
• Then call redraw() in mouseClicked().
• Keep your drawing stuff in draw() btW.

GoToLoop

https://Processing.org/reference/redraw_.html

Puddle

It is event-driven, however we are supposed to use that which is mentioned in classes during this assignment. Noloop() and reDraw() have not been mentioned.

However I tried that and placed the content of the drawScreen() function inside the draw().

Still produces the same issue.

GoToLoop

Sorry, I dunno what is going there either. X_X

Puddle

I managed to solve the problem during a hot shower (I think as it has not happened again) and thought you might wanted to know what was causing the problem.

I realized that rectMode() is changed to the center of a rectangle inside the invokeFunction() function.

If there is any type of parallel or out of order execution going on in the background, rectMode() might already be changed at times (and this could result in weird patterns when it occurs and when it doesn't).

Adding rectMode(CORNER) before drawing the rectangle solved the issue.

Might be some normal type of behavior but it caught me off guard.

jeremydouglass

Have you actually experienced the issue in the sketch you provided? It looks incomplete / broken.

If you can't verify the issue with what you are sharing then you may have already taken out the part causing the problem.

Puddle

@jeremydouglass, the post above yours mentions the solution to the problem I had.

I could not provide more of the sketch as other students are working on the same assignment and it's graded. So I had to keep it a bit cryptic.

jeremydouglass

Got it.

You can also use pushStyle and popStyle to isolate your call to rectMode -- that is easier and cleaner than trying to set it back later to whatever you think it was.

GoToLoop

If there is any type of parallel or out of order execution going on in the background, ...

• Theoretically there shouldn't be any concurrency when using the regular Processing events.
• However, many changes happened on how things are rendered in Processing 3.
• The main Processing Thread is called "Animation Thread".
• However, depending on which renderer is chosen & whether or not noLoop() is active, the actual Thread which dequeues events may happen not to be the "Animation Thread".
• Regardless, code inside or invoked from draw() is run by the "Animation Thread".
• In order to know which Thread is currently executing a function, just have this statement: println( Thread.currentThread() );.
• Just place that statement inside your mouseClicked() to make sure which Thread is responsible to run it. :ar!