Shape primitive flickering while multithreading

Zebru

Hello everyone!

First time posting so a little bit nervous :-)

The thing is that I'm doing an application with kinect and my first approach was to have both depth detection/processing and drawing in the same thread. Worked fine but sometimes it draws a bit slow.

Now I moved the Kinect detection/processing part to another thread. This has the typical loop of going through the kinect.getRawDepth() array and draw in another PImage the pixels which are enough close to the camera. So I'm doing ther pixel manipulation etc. The problem is that since I did that, the primitive shapes drawed in the main loop are flickering like hell. This only happens with primitives, pictures, images are totally fine.

Also, if I comment only the part of the for loop, everything is fine. Any ideas why this is happening? How to solving it? Thank you very much in advance!

This is the code of run() inside thread:

void run(){
  while(true){
    if(!calibrating){
      raw_depths = kinect.getRawDepth();
      for (int i = 0; i < raw_depths.length; i++) {        
        if(raw_depths[i] > LIMIT) depth_image.pixels[i] = color(0);
        else depth_image.pixels[i] = color(255);
      }

      depth_image.updatePixels();

      opencv.loadImage(depth_image);
      opencv.threshold(ERODE_THR);
      opencv.erode();
      depth_image = opencv.getSnapshot();
      // Compute BLOBS
      theBlobDetection.computeBlobs(depth_image.pixels);
    }
  }
}

KevinWorkman

Is there a reason you moved this to another thread?

You can't modify and use variables from two different threads without synchronizing your logic. Otherwise, you get situations like yours where the data is changing while you're trying to render it.

You need to synchronize your code so that you aren't changing the data while you're drawing it. But at that point, do you really need to be using different threads?

GoToLoop

color() is a horrible chain of rag functions. It's completely unsafe to multithreading! :-SS

Replace color()'s arguments w/ their corresponding hexadecimal actual aRGB value:
https://Processing.org/reference/color_datatype.html

Of course, depending on what you're doing w/ your thread shared objects, you may end up needing to use synchronized () at some places. [-O<

Zebru

Thank you very much for the replies! So fast... The thing is that I don't use any information of the kinect processing thread to draw the primitives in the main thread.

I tried to use color like you said: stroke(#FFFFFF).

No luck at all! :,(

GoToLoop

I tried to use color like you said: stroke(#FFFFFF);.

Another extremely important thing: never modify sketch's canvas outside the "Animation" Thread! [-X

If you really need to, create an exclusive PGraphics for your other Thread.

Then "stamp" that on the main canvas via image(), set() or background() under the "Animation" Thread.

Zebru

Pixel manipulation counts as modifying the canvas? What I mean is that the thead which is doing the kinect processing does pixel manipulation but never "shows" anything. I'm just modifying a PImage. You can see that in the piece of code of my 1st message.

GoToLoop

• What we call the canvas is actually an instance of class PGraphics.
• Which in turn is also subclass of class PImage.
• And yes, pixel manipulation counts as modifying the canvas, if it's acting upon the main pixels[].
• However, if it's your own off-buffer layer, be it the simpler PImage or the full-blown PGraphics, it's safe to mutate it outside the "Animation" Thread.
• Yes, I can see in your posted excerpt you're only mutating PImage objects.
• But at the same time, no variables were declared there. They're pre-existing.
• So I wonder if some other Thread is also accessing/modifying them... :-?

Zebru

Hi! Thank you again for your answer. You are right, PImage depth_image is global but should be at least instance variable. I'm not accessing that image outside the thread. I don't know... You have given me some hints where to find the problem, Thank you! If I cannot solve it, I will use images instead of primitive shapes.

Cheers!