Home/ Questions/Q 578451
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T14:15:42+00:00

I am building an application that will do some object tracking from a video

  • 0

I am building an application that will do some object tracking from a video camera feed and use information from that to run a particle system in OpenGL. The code to process the video feed is somewhat slow, 200 – 300 milliseconds per frame right now. The system that this will be running on has a dual core processor. To maximize performance I want to offload the camera processing stuff to one processor and just communicate relevant data back to the main application as it is available, while leaving the main application kicking on the other processor.

What do I need to do to offload the camera work to the other processor and how do I handle communication with the main application?

Edit:
I am running Windows 7 64-bit.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Basically, you need to multithread your application. Each thread of execution can only saturate one core. Separate threads tend to be run on separate cores. If you are insistent that each thread ALWAYS execute on a specific core, then each operating system has its own way of specifying this (affinity masks & such)… but I wouldn’t recommend it.

    OpenMP is great, but it’s a tad fat in the ass, especially when joining back up from a parallelization. YMMV. It’s easy to use, but not at all the best performing option. It also requires compiler support.

    If you’re on Mac OS X 10.6 (Snow Leopard), you can use Grand Central Dispatch. It’s interesting to read about, even if you don’t use it, as its design implements some best practices. It also isn’t optimal, but it’s better than OpenMP, even though it also requires compiler support.

    If you can wrap your head around breaking up your application into “tasks” or “jobs,” you can shove these jobs down as many pipes as you have cores. Think of batching your processing as atomic units of work. If you can segment it properly, you can run your camera processing on both cores, and your main thread at the same time.

    If communication is minimized for each unit of work, then your need for mutexes and other locking primitives will be minimized. Course grained threading is much easier than fine grained. And, you can always use a library or framework to ease the burden. Consider Boost’s Thread library if you take the manual approach. It provides portable wrappers and a nice abstraction.

    • 0