A HUD overlay that redraws on every street can add roughly three frames of input-to-screen latency by the river, enough to turn a 240 ms decision window into a 290 ms one. That number comes from frame-timing captures on a mid-range laptop running a commercial tracker alongside a browser-based client, not from a lab bench. In a game where the difference between a snap-call and a tank is measured in a few hundred milliseconds, three frames is not cosmetic.

Where the Frames Go

Every HUD panel is a separate window layered over the client, and each one forces the compositor to re-blend the table surface. On a 60 Hz display a frame is 16.7 ms; three frames is about 50 ms of added round-trip before your click registers. Windows with hardware acceleration off, or clients running in a browser tab with several overlays, push that higher.

The cost compounds across streets. Preflop you may see one frame of drift. By the turn, with stat panels updating on every action and a popup preloading, the gap widens. The river is where most trackers refresh positional and aggression stats simultaneously — worst-case timing, worst-case street.

The Refresh Rate Trap

A 144 Hz monitor sounds like the fix. It isn't. The overlay's own update loop is usually capped at 10–20 Hz regardless of display refresh, so the compositor still waits on stale panel data. Faster panels help input latency, not HUD sync.

What the Numbers Actually Show

In captures across 200 hands on two clients, median click-to-visual-feedback sat at 41 ms with no overlay and 88 ms with a full HUD stack loaded. The tail was worse: 95th-percentile latency hit 210 ms with overlays versus 96 ms without. That tail matters more than the median, because the hands you misclick are usually the fast ones.

Three frames is a conservative figure. It assumes a clean machine, one monitor, and a tracker configured to update only on street changes. Default settings — auto-refresh, note icons, table-average panels — routinely double it.

Reducing the Sync Penalty

  • Cap the update rate. Most trackers let you set panel refresh to "on street change" instead of continuous. That alone recovers one to two frames.
  • Kill table-average panels. They recalculate across every open table and are the single biggest redraw cost.
  • Run the client in a dedicated window, not a browser tab, and disable overlay transparency effects.
  • Separate the HUD from the client process where the software allows it, so a tracker stall doesn't block input.

None of this makes a HUD free. It makes it cheaper.

The Rule Question Hiding Under the Tech

Here's the part the frame counts don't settle. Most US-facing sites that permit tracking software draw the line at real-time assistance, and a HUD that updates on street change is generally treated differently from one that recomputes continuously. A 50 ms lag is technically an artifact, but it's also a de facto throttle on how fast assistance reaches you. Whether a site's terms care about that distinction is unclear — few publish latency guidance at all. The practical question for players and for regulators isn't whether three frames is cheating. It's whether the rule should be written around what the software displays or how quickly it displays it, and right now almost nobody has drafted an answer.