帧率读数改为"采集时刻"的到达率，并在旁边显示每帧耗时 - What: sdk_worker 的采集循环里把帧率与时间戳的取样点从"算完之后"(t1) 改成"取到这一帧的时刻"(t0)——frame_times、SIGPkt.mono_t（实时分支）与 last_frame_mono（断线判定）都用 t0，所以 16.7 FPS 现在明确表示"帧是以这个速率到达的"，而不是把流水线耗时当成帧率；process_ms 的终点从 process_chain 之后改到 read_forces_from_sensor 之后（t_done），因此它终于涵盖这一帧的**全部**开销（此前漏掉力值读取）；last_frame_at 仍取 t1（compute chain 结束）作为节拍相位参考，行为不变（帧率测试仍然通过）。app_window 在 视图▸显示帧率 打开时把每帧耗时一起显示在轨道摘要里："16.7 FPS · 58 ms"，并新增 _latest_process_ms（随会话/回放清空）。tests/test_ui_smoke.py 增加一项断言：轨道同时给出速率与耗时，且没有耗时数据时仍只显示速率。 - Why: 用户看到 Studio 上方显示 16.67 fps 而不是 30，问是不是显示错了。查证结论：这个数字来自 packet.fps，是采集循环真实的"到达率"，记录里的行数也是它——不是界面 bug；但它有两个缺陷让这个数字**无法单独判读**：(1) 取样点在算完之后，于是它把本机流水线耗时混进了"设备帧率"；(2) 旁边没有每帧耗时，而"16.7 FPS"既可能是摄像头只给 16.7，也可能是流水线跟不上 30（实测：每帧 ≤30 ms 时循环仍能跑满 29.3 fps；40/50/60/70 ms 分别掉到 24.7/19.8/16.5/14.1 fps——16.67 恰好对应每帧约 60 ms）。本机 app 配置（365x365 拼接、dis_mode=3）在 480p 素材上 process_chain+力值读取只要 ~10 ms（上限约 100 fps），因此本次报的 16.67 不可能是这台机器上这个配置的流水线瓶颈；两种可能必须靠耗时数据区分。 - Verification: pytest shared/tests/test_worker_frame_rate.py 4 项全过（30 fps 设备仍被消费在 29.3 fps）；studio 全量 90 passed（新增 1 项）；ui_check 554 项检查 0 失败；真实 SDK 复测：文件源 55.4 fps 到达率、每帧 18.2 ms（含力值读取）。 - Not in this change: frames.csv 仍未记录 process_ms（下次改记录格式、加未滤波 17 列时一并加，避免连做两次版本升级）；未动节拍逻辑本身。

shared/src/orisys_app_shared/acquisition/sdk_worker.py

@@ -735,6 +735,11 @@ class SdkAcquisitionWorker(RecordSinkMixin):
                             break
 
                 t0 = time.perf_counter()
+                # ``t0`` is when this frame was *collected*: the device's own rate
+                # and the frame's acquisition time are measured from here, not
+                # from the end of its processing (that would report how long the
+                # pipeline took, dressed up as a frame rate).
+                #
                 # ``CaptureSource.read_latest`` hands back the newest frame and,
                 # until the pipeline produces another one, that **same** frame
                 # again. Treating the repeat as a new sample doubled every
@@ -772,7 +777,7 @@ class SdkAcquisitionWorker(RecordSinkMixin):
                 compute_error = ""
                 # The frame's acquisition time, so an event that happens on this
                 # frame is dated when it happened rather than when it was queued.
-                frame_mono = max(0.0, time.perf_counter() - self._mono_t0)
+                frame_mono = max(0.0, t0 - self._mono_t0)
                 try:
                     # Applying new coefficients is reported separately from the
                     # compute chain: a rejected document is an operator error,
@@ -797,7 +802,11 @@ class SdkAcquisitionWorker(RecordSinkMixin):
                 chain_depth, chain_error = process_chain(sensor)
                 compute_error = compute_error or chain_error
                 t1 = time.perf_counter()
-                frame_times.append(t1)
+                # The rate is measured between *collections* (``t0``), so it is
+                # the rate the frames arrived at. Measuring it after the compute
+                # chain instead made the rail report the loop's own cost as if it
+                # were the device's rate.
+                frame_times.append(t0)
                 cutoff = t1 - FPS_WINDOW_S
                 frame_times = [t for t in frame_times if t >= cutoff]
                 # A *rate*, not a count: counting arrivals in a one-second window
@@ -807,6 +816,10 @@ class SdkAcquisitionWorker(RecordSinkMixin):
                 span = frame_times[-1] - frame_times[0] if len(frame_times) > 1 else 0.0
                 fps = (len(frame_times) - 1) / span if span > 0.0 else 0.0
                 forces = read_forces_from_sensor(sensor, config_ref=mode.config_ref)
+                # Everything this frame cost, including the force readout — the
+                # number that says whether the loop can still keep up with the
+                # device, which the frame rate alone cannot.
+                t_done = time.perf_counter()
                 invalid_reason = forces.get("invalid_reason") or compute_error
                 raw_frame = _ensure_bgr(raw)
                 # The frame the chain above actually consumed, kept as the
@@ -825,10 +838,10 @@ class SdkAcquisitionWorker(RecordSinkMixin):
                     mono_t=(
                         frame_id * frame_period
                         if is_file
-                        else max(0.0, t1 - self._mono_t0)
+                        else max(0.0, t0 - self._mono_t0)
                     ),
                     fps=fps,
-                    process_ms=(t1 - t0) * 1000.0,
+                    process_ms=(t_done - t0) * 1000.0,
                     normal_force=forces["normal_force"],
                     shear_x=forces["shear_x"],
                     shear_y=forces["shear_y"],
@@ -857,7 +870,10 @@ class SdkAcquisitionWorker(RecordSinkMixin):
                 self._emit(packet)
                 frame_id += 1
                 saw_frame = True
-                last_frame_mono = t1
+                last_frame_mono = t0
+                # The pacing phase reference stays the end of the compute chain:
+                # the loop waits out the rest of the frame period from there, and
+                # that is the behaviour the frame-rate tests pin.
                 last_frame_at = t1
             except Exception as exc:
                 self._set_end_reason("error")