Потоки с Kinect

Я пишу приложение С#, которое использует Kinect, я беру вывод в настоящее время и записываю его в ресурс Shader и отображая его как текстуру, моя проблема в том, что Kinect (по-видимому) работает только со скоростью 30 кадров в секунду, поэтому это плохо влияет на мою работу.

Какой лучший способ преодолеть это, многопоточность? Есть ли какая-то модель дизайна, которая поможет в этом типе проблемы? Насколько я могу судить, я могу захотеть, чтобы kinect обрабатывал данные в потоке, а затем получал к нему доступ, когда процесс завершен, но я не уверен, с чего начать безопасно.

Спасибо за любые советы, которые вы можете предложить.

В настоящее время я использую OpenNI для драйверов kinect/api и SlimDX для стороны рендеринга directX.

Ответ 1

Я раньше не работал с Kinect, и вы не указали, какие драйверы/обертки вы используете, но я подозреваю, что это, вероятно, не имеет значения.

Вам, возможно, понадобится следующее:

Отредактируйте цикл обновления для Kinect на свой собственный поток. Это приведет к тому, что ваша прикладная логика будет работать как можно быстрее, не останавливаясь, ожидая обновления от оборудования kinect.
Вам нужно будет "заблокировать" данные изображения/глубины на каждом проходе, в то время как kinect заполняет новые данные.
Если процесс заполнения Kinect данными длится два, вы можете попробовать буферизировать данные изображения и глубины, если драйверы этого еще не сделали. Это означает, что вы сохраняете две копии в памяти и читаете одну, а другая записывается.

Для отличных уроков по потоковому использованию в С# я всегда рекомендую Albahari Threading в С#. Я бы также рекомендовал, если вы хотите получить более конкретную информацию о том, что вы можете сделать для ускорения вашего приложения, вероятно, вы должны отредактировать свой вопрос и добавить подробные сведения о том, как вы его структурировали сейчас, и какую оболочку/драйвер вы используете и т.д.

Ответ 2

Любая разработка с Kinect, требующая высокой производительности, должна использовать модель объединения, а не модель событий. И в дополнение к этому, ваш лучший вариант - это открыть поток и выполнить операции объединения. Вы можете использовать слишком потоки с моделью событий, чтобы выполнять длительные операции, а не замораживать пользовательский интерфейс.

И вы можете увидеть это: http://msdn.microsoft.com/en-us/library/hh973076