Question

I know there is a better way to do this. I’m fairly new to multithreaded programming, however raising my event on a new thread like the code below allows my application to get a higher FPS with the Kinect.

When the object of my KinectService class is initalized, inside that method I do this:

Thread t = new Thread(() =>
{
    sensor.AllFramesReady += new EventHandler<AllFramesReadyEventArgs>(sensor_AllFramesReady);
    KinectSensor.KinectSensors.StatusChanged += new    EventHandler<StatusChangedEventArgs>(Kinects_StatusChanged);
});
t.Start();

Which in turn calls this method:

void sensor_AllFramesReady(object sender, AllFramesReadyEventArgs e) 
{
    using (DepthImageFrame depthFrame = e.OpenDepthImageFrame())
    {
        if (depthFrame == null)
        {
            return;
        }

        byte[] pixels = GenerateColoredBytes(depthFrame);            
        int stride = depthFrame.Width * 4;
        BitmapSource test = BitmapSource.Create(depthFrame.Width, depthFrame.Height,
                    96, 96, PixelFormats.Bgr32, null, pixels, stride);

        test.Freeze();

        if (FrameChanged != null)
        {
            FrameChanged(test);
        }
    }    
}

FrameChanged(test) passes the newly created bitmap back to the viewmodel which then updates the source of an image. Is this a terrible way to do this? Giving an event it’s own thread feels wrong, however it makes my application run a lot faster. Any pointers?

Answer 1

Events are fired on the same thread that called them, and there isn’t anything in the documentation for KinectSensor.AllFramesReady to say otherwise.

So in your code sensor.AllFramesReady won’t fire another event until your event handler (sensor_AllFramesReady) returns.

A better way to do it possibly is to change your event handler to spawn off a thread and immediately return. I.e.

void sensor_AllFramesReady(object sender, AllFramesReadyEventArgs e)  
{
    var frameReadyThread = new Thread(() =>
    using (DepthImageFrame depthFrame = e.OpenDepthImageFrame()) 
    {
        //
    }
    frameReadyThread.Start();
}

You will need to do some synchronisation though within frameReadyThread to ensure that the following is true,

1. Frames are not handled out of order, you don’t want Frame 1 to update after Frame 2
2. Frames are abandoned when they are no longer doing useful work rather than steal CPU.
3. If you’re implementing your own thread dispatcher, that you scale appropriately to the machine you are on. For example, if you have access to 8 cores, and your handler code is CPU bound, its unlikely that you’ll see any benefit if you have more than 8 threads.