01 / The Problem & Hard Constraints

The Problem & Hard Constraints

Sim-racing telemetry engines broadcast high-frequency data (RPM, tire temps, suspension travel) over UDP at 60Hz to 120Hz. Rendering this data on a mobile or edge display introduces severe UI thread contention.

• Zero GC Stutter: Standard JSON parsing or object allocation at 120Hz triggers the Garbage Collector (GC) every few seconds, causing catastrophic frame drops (micro-stutters) during a race.
• Sub-16ms Render Pipeline: UDP ingestion, data decoding, state mutation, and UI repainting must complete in under 8.3ms to sustain a 120 FPS dashboard.
• Battery/Thermal Budget: Continuous high-refresh-rate rendering quickly overheats edge tablets; optimization requires bypassing heavy DOM or Widget-tree rebuilds.

02 / Architecture & Core Design Decisions

Architecture & Core Design Decisions

• Background UDP Isolate: The network listener runs on a completely separate OS thread (Isolate), ingesting raw UDP binary packets and preventing network I/O from blocking the main UI render loop.
• Zero-Allocation Binary Parser: Bypassed JSON entirely. The simulator broadcasts packed C-structs over UDP. The background worker parses raw bytes directly into pre-allocated Float32List memory buffers. No new objects are instantiated during the race, dropping GC pressure to zero.
• Direct Canvas Repainting: Instead of using standard UI components (which trigger expensive layout recalculations), gauges are drawn directly to the GPU using low-level Canvas/WebGL APIs, mutating only the specific pixels that change.

03 / Deep Technical Challenges & Solutions

Deep Technical Challenges & Solutions

The Challenge: Thread Synchronization Latency. Passing 120 state updates per second between the UDP worker thread and the UI thread via standard message passing caused queue bloat and a 3-frame delay (desyncing the RPM audio from the visual tachometer).

The Solution: Shared Memory & Atomic Locks. I implemented a SharedArrayBuffer (or Dart FFI shared pointer). The UDP thread writes telemetry directly to this shared memory region using atomic operations. The UI thread simply reads the memory pointer at the start of every display refresh cycle (v-sync). This bypassed the message-passing queue entirely, reducing telemetry-to-glass latency to <1ms.