How fast should a Whiteout Survival bot be?

Bots get sold on feature lists. The thing actually separating a good bot from a bad one is a number that almost nobody publishes: capture-to-tap latency.

What capture-to-tap actually means

Every bot loop looks the same:

1. Capture a frame from the emulator
2. Recognize what's on screen
3. Decide what to do
4. Send a tap to the emulator

The wall-clock time from step 1 to step 4 is your latency. Multiply it by every interaction in a daily routine — call it 200 taps per instance per day for serious farmers — and that's a real number.

What "fast" actually means

• Under 100 ms: imperceptible to a watcher. Looks like a human with too much coffee.
• 100–250 ms: visibly fast. What good native bots do.
• 250–500 ms: visibly automated but acceptable.
• 500–1000 ms: slow. Routine that should take 5 minutes takes 15.
• Over 1 second: "runs very slow…takes hours". The complaint pattern.

How we measured ours

We instrumented our capture pipeline with high-resolution timers around every phase: capture, recognize, decide, transport, ack. We ran the standard daily routines (help allies, claim rewards, gather, hospital, train) on a single MuMu Player Global instance. Hardware: Ryzen 5 7600, 32 GB RAM, NVMe SSD, no other emulator load.

Telemetry rolls up to the admin dashboard nightly. The numbers below are the latest 7-day rolling p95 across the production fleet — not cherry-picked benchmarks.

The numbers

• Median (p50): 92 ms
• p95: 138 ms
• p99: 174 ms

The p99 number is what matters most. p99 is your worst 1% of taps — that's the recognition step hitting a frame that's mid-fade or matching a low-confidence template. Even there, we stay under 200 ms.

Why we're fast

• Native C# capture. Stacks that lean on Python or Java image-processing bindings pay for each round-trip through the interop layer. We talk to the device directly in .NET and the framebuffer never leaves managed memory.
• Templates embedded in the binary.We don't load PNGs from disk on each match. Templates ship as embedded resources and are decoded once at startup.
• No screenshot file round-trip. We capture the framebuffer in memory and recognize against it directly. No temp-file write, no disk fsync, no PNG decode.

Why this number is rarely published

It's a hard metric to commit to. A specific latency figure is a clear, falsifiable claim — harder to stand behind than vague "industry-leading" copy — and measuring it well takes deliberate instrumentation that not every team builds. So most pages skip it.

We'd rather put ours on the table. If you run a bot and publish yours too, even better — a shared metric is how buyers actually compare.