Skip to content

docs(input-latency): correct against the ash renderer and the real de… - #82

Merged
joschaschmiedt merged 1 commit into
mainfrom
docs/input-latency-refresh
Jul 10, 2026
Merged

docs(input-latency): correct against the ash renderer and the real de…#82
joschaschmiedt merged 1 commit into
mainfrom
docs/input-latency-refresh

Conversation

@joschaschmiedt

Copy link
Copy Markdown
Contributor

…vice set

INPUT_LATENCY.md had drifted from the code in two directions.

Input side (§4–§6, §8):

  • §5 documented AnimExternalPos, AnimZmqPos, AnimMousePos and AnimGamepadPos. None exist. The only variant is ExternalPosition2D, and it is a stub whose advance arm returns false without ever reading shm. Say so.
  • The sketch used impl Animation for … over Box<dyn Stimulus>; trait objects are ruled out in favour of the flat enum.
  • The design assumed every source is an absolute position. A wheel or encoder is cumulative and a gamepad stick is a rate. Document all three semantics, and why a cumulative accumulator (not a per-write delta) is the only race-free contract.
  • §4 recommended the shared_memory crate, never a dependency. The vtl crate already solves shm here; mirror it. Add the seqlock, f64 accumulators and the writer heartbeat that a bare f32[2] lacks — the heartbeat is a safety requirement, not a nicety.
  • Shared memory is a backend, not the interface: gamepad and keyboard are in-process, which yields --input-override for free.
  • Devices are declared in rig-config.toml, not in every animation.

Render side (§10–§14):

  • §10 used wgpu::PresentMode and a clap CLI snippet. The renderer is ash and the server does not depend on clap. FIFO is already the implemented default.
  • §11 claimed presentation timestamps must be emulated because "wgpu does not expose" them. The DRM backend already latches real vblank timestamps and FrameStats is implemented; the actual gap is that none of it is exposed over the protocol.
  • §12.1 had the render thread taking the read lock first; it takes the write lock.
  • §13.3/§14 documented Windows. There is no target_os = "windows" code.
  • §13.4 said to measure before adding core_affinity; rig_config.rs already parses render_cpu_core and ignores it (Apply CPU core affinity from config (currently parsed but ignored) #65).

Refs #77, #78, #79, #80, #81

Claude-Session: https://claude.ai/code/session_01TovGgCFRVaGjUhKHLVKgUF

…vice set

INPUT_LATENCY.md had drifted from the code in two directions.

Input side (§4–§6, §8):
- §5 documented AnimExternalPos, AnimZmqPos, AnimMousePos and AnimGamepadPos.
  None exist. The only variant is ExternalPosition2D, and it is a stub whose
  advance arm returns false without ever reading shm. Say so.
- The sketch used `impl Animation for …` over `Box<dyn Stimulus>`; trait objects
  are ruled out in favour of the flat enum.
- The design assumed every source is an absolute position. A wheel or encoder is
  cumulative and a gamepad stick is a rate. Document all three semantics, and why
  a cumulative accumulator (not a per-write delta) is the only race-free contract.
- §4 recommended the `shared_memory` crate, never a dependency. The `vtl` crate
  already solves shm here; mirror it. Add the seqlock, f64 accumulators and the
  writer heartbeat that a bare f32[2] lacks — the heartbeat is a safety
  requirement, not a nicety.
- Shared memory is a backend, not the interface: gamepad and keyboard are
  in-process, which yields --input-override for free.
- Devices are declared in rig-config.toml, not in every animation.

Render side (§10–§14):
- §10 used wgpu::PresentMode and a clap CLI snippet. The renderer is ash and the
  server does not depend on clap. FIFO is already the implemented default.
- §11 claimed presentation timestamps must be emulated because "wgpu does not
  expose" them. The DRM backend already latches real vblank timestamps and
  FrameStats is implemented; the actual gap is that none of it is exposed over
  the protocol.
- §12.1 had the render thread taking the read lock first; it takes the write lock.
- §13.3/§14 documented Windows. There is no target_os = "windows" code.
- §13.4 said to measure before adding core_affinity; rig_config.rs already parses
  render_cpu_core and ignores it (#65).

Refs #77, #78, #79, #80, #81

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TovGgCFRVaGjUhKHLVKgUF
@joschaschmiedt
joschaschmiedt merged commit 3aae20f into main Jul 10, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant