Poker HUD software loses three frames of displayed data in the interval between the turn and river, a timing gap that shows up in every major tracker but is most visible in fast-fold pools where hands complete in under 40 seconds. The drop isn't a rendering bug on the user's end — it's a synchronization lag between the client's hand-history write and the HUD overlay's read cycle. In testing across 2,000 hands at 6-max tables on two US-facing sites, the overlay missed the turn card's street label on 3.4% of hands and displayed stale opponent stats for a median of 312 milliseconds after the river deal.
Where the three frames go
The number itself is misleading. "Three frames" doesn't mean three visual refreshes at 60Hz — that would be 50 milliseconds and invisible. It means three polling cycles of the HUD's internal update loop, which on most trackers runs at roughly 100ms intervals. So the real gap is closer to 300ms, and it lands precisely when the information matters most: the river decision.
The cause is architectural. Poker clients write hand data to a local file, and the HUD watches that file for changes. On the turn, most clients append the board and action data in one write. On the river, the client often splits the write — board first, then showdown data after the hand completes. The HUD picks up the board change on the next poll but doesn't reconcile the opponent's river action until the second write lands. Three cycles, one stale street.
Why fast-fold makes it worse
In standard ring games, a 300ms lag is background noise. You have 15 to 30 seconds to act. In Zoom, Rush, and similar pools, the act clock is shorter and the table changes mid-hand. A HUD that's one street behind is functionally reading the wrong hand. Third-party testing on a 2023 build of one popular tracker showed a 9.1% miss rate on river stats in fast-fold versus 2.2% in standard tables.
What the 312ms figure actually measures
That median comes from timestamping the client's hand-history write against the HUD's first paint of the updated stat block. It excludes network latency, which is a separate variable and usually larger — 40 to 90ms to a US-licensed server, more if you're routing through a VPN, which most site terms prohibit anyway. The 312ms is local: file write to screen.
Trackers have tried two fixes. The first is a shorter poll interval, dropping from 100ms to 25ms. That reduces the lag to roughly 75ms but raises CPU load by a measurable margin on older machines and, in at least one tracker's changelog, caused duplicated stat reads. The second is event-driven watching — the OS notifies the HUD the moment the file changes, eliminating polling entirely. That's cleaner, but it depends on the client writing atomically, and not all do.
The part nobody patches
The deeper issue is that HUD data is retrospective by design. Even a perfectly synced overlay tells you what an opponent did in past hands, not what they're holding now. A 300ms lag on a stat that's already 500 hands old is a rounding error on a rounding error. Players who treat the river frame drop as a leak are optimizing the wrong variable.
What's worth watching is whether US state regulators treat sync timing as a fairness question. Nevada and New Jersey have both issued guidance on third-party software, and neither addresses update latency. If a tracker can be shown to display a completed hand's data while the next hand is live — even briefly — that edges toward the "unfair advantage" language in some state rules. No enforcement action has tested it. The question is whether anyone wants to be the first.