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. Most paid bots use Python or Java with image-processing bindings. Each round-trip through the interop layer adds milliseconds. We talk to ADB 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 competitors don't publish theirs

Honestly, we don't know. We suspect three things:

1. The number isn't flattering, so it's easier to dodge.
2. It would be a clear, falsifiable claim — which is harder to defend than vague "industry-leading" copy.
3. Most bot teams aren't measuring it themselves.

If you're reading this and your bot vendor publishes theirs, hat-tip. We'll cite you in the next revision.