Fix motion capture UI freezes: throttling, async camera open/scan, stale poll

Several compounding freeze sources in plugins/motion_capture/:
- tracker.py: _run_real had no frame-rate cap independent of the camera's
  configured fps (up to 120fps/2560x1440 was possible), and no bound on
  consecutive failed reads — a camera that "opens" (cv2 isOpened() can lie,
  seen with Windows MSMF/obsensor) but never actually delivers frames would
  get hammered forever. Added a 20Hz processing cap, a real test-read before
  committing to a camera, and a give-up-after-30-failures fallback to
  simulation.
- tracker.py/device.py: cv2.VideoCapture() opening a real camera is a slow,
  blocking call — CameraTracker.start() used to do this synchronously on
  the caller's thread, which froze the whole app when ProfileManager.apply()
  called it during profile load. Now runs on the background thread; status
  reporting (CameraDevice) moved to an on_result callback since the caller
  can no longer learn the outcome synchronously.
- window.py: the Camera View preview ran a 30Hz GUI-thread timer doing a
  full-frame copy + QImage/QPixmap rebuild every tick unconditionally (no
  visibility check) — dropped to 10Hz and skips entirely when hidden.
  Camera enumeration (list_cameras(), up to 8 sequential cv2.VideoCapture
  probes) also ran inline in the window constructor, blocking it open the
  same way camera_panel.py's CameraScanThread already avoided for the Add
  Device dialog — moved to the same async pattern here.

config_window.py: separately, ConfigWindow._dev_poll (device status label
refresh) was stopped in closeEvent and never restarted, since MainWindow
reuses the same ConfigWindow instance across opens — invisible before
because connect() was synchronous, but with the above change a device can
sit in CONNECTING for a while, and a stale poll made that look stuck
forever after reopening the window. Restart it in showEvent.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions