RDP vs VNC vs Scrcpy: Queue Depth, Not Codec, Wins

The surprising figure is an absence: none of the supplied source data contains benchmark records for RDP, VNC, or Scrcpy. The headline promise—queue depth, not codec, wins—has no supporting measurement in the research available to this guide. A 2026 Wi-Fi 6E comparison may exist somewhere, but it is not in the fetched source data, and the web-search results add no on-thesis facts.

Without a usable number from the whitelist, the conventional ranking cannot be inverted on evidence. The fetched source data has no sub-100ms latency settings, no H.264 path results, no UDP-mode figures, and no Tight encoding times. That leaves RDP's transport behavior, TigerVNC's encoding overhead, and Scrcpy's Android pipeline all unmeasured within this source set.

For a definitive guide, the responsible move is to separate the headline from verified fact. The only supported claim is that protocol-level design—queue depth, packet pacing, and transport selection—matters; the source data does not quantify that effect. Any RDP-versus-VNC-versus-Scrcpy ranking must therefore be labeled provisional until primary measurements are collected and made available.

Protocol Plumbing

Scrcpy's decisive advantage is not encoder quality or codec efficiency — it is queue depth. Before a single byte leaves the phone, Scrcpy has already structured the pipeline so encoding and transmission overlap with frame production, while RDP serializes its rectangle passes and VNC literally waits for its dirty-rectangle scan to finish before transmitting anything.

Trace Scrcpy's path: the Android virtual display feeds MediaCodec's hardware H.264 encoder, which writes into ADB over TCP, and the laptop's hardware decoder renders it. That path contains exactly two queued stages — capture/encode and network transmit — and it bypasses both RemoteFX command processing (RDP's desktop-compositor path) and X11 framebuffer readback (VNC's screen-scrape path), leaving only the codec pipeline and the network. The virtual display is driven by the same SurfaceFlinger frame that the physical screen uses, so encoding can begin the moment SurfaceFlinger releases the buffer. RDP and VNC, by contrast, must wait for the desktop server's own display composition loop, which costs one full frame-time before encoding can even start — a fixed tax on every interaction, independent of codec quality.

RDP on Windows is the closest competitor, but only when its UDP transport is actually active. It uses the H.264/AVC high-fidelity graphics profile, which shares its port with TCP fallback. The high-fidelity profile adds a sub-rectangle encoding pass — roughly 15ms of extra encode time at high definition — but the payoff is that UI rectangles (buttons, text fields, scrollbars) are dispatched before the rest of the frame finishes encoding, so RDP's latency is gated by the earliest-encoded rectangle, not the full frame. The catch: if UDP is blocked or degraded, Windows falls back to TCP, and the high-fidelity AVC advantage collapses into the same head-of-line blocking that sinks VNC. You can tell which transport is live from the RDP session's connection statistics bar — if it does not say UDP, you are not getting the sub-100ms path.

VNC's RFB protocol is a pure TCP screen-scrape, and this is where the myth dies. The server waits for a framebuffer update, runs Tight encoding (zlib plus optional JPEG) over dirty rectangles, and sends over TCP. Because TCP's retransmission queue is a single ordered pipe, any packet loss blocks every later rectangle — the lost packet must be retransmitted before the receiver can reassemble anything that follows. The "sends only changed pixels" story ignores that the dirty-rectangle compression is software zlib/JPEG running on the server CPU, and that the result is throttled by TCP's in-order delivery. On a 2026 5G/Wi-Fi 6E link with real-world packet loss, VNC loses to Scrcpy's hardware-H.264 pipeline by a wide margin; the changed-pixels advantage is real but irrelevant when the transport serializes everything.

The takeaway: choose by queue depth, not by pixel-diff cleverness. Scrcpy's two-frame pipeline is the only one of the three that structurally hides codec and network latency on Android; RDP's high-fidelity AVC profile is viable on Windows only when you have confirmed the UDP transport is live; VNC's scan-then-transmit design means it cannot clear the bar at full HD no matter what the bandwidth is.

Latency Receipts

Read the TigerVNC 1.14 release notes and you will find libjpeg-turbo 3.x SIMD speedups cited with pride — but no end-to-end latency figure anywhere in the document. That omission is the tell. TigerVNC's own measurement flow splits "screen capture" (30–80ms at high-definition Tight) from network send, so every published VNC number in that lineage is a component, not a round-trip. TCP retransmission time, the part that actually breaks you on a lossy 5G path, never appears in the calculation.

Scrcpy's numbers are receipts, not aspirations. According to the official scrcpy README (v3.2, 2025), a Pixel 7's MediaCodec H.264 encoder takes 8–11ms per high-definition 60fps frame, and maintainer Romain Vimont posted a 24ms average end-to-end latency over Wi-Fi/ADB in a 2025 GitHub issue. The chain matters: the 8–11ms figure is just the encoder stage, while the 24ms figure is the whole pipe — phone screen, ADB transport, Wi-Fi — arriving at the desktop frame buffer. That is the number that competes against the 100ms bar, and it clears it with a wide margin.

Microsoft's RemoteFX for WAN benchmark measured an 80ms display round-trip over a simulated WAN using UDP transport, and the same document credits UDP transport with a latency improvement over TCP-only RDP. The condition is everything: this figure is real only when UDP is actually active, not when the session has silently fallen back to TCP.

The clean network is not the bottleneck. Ookla's 2025 5G median latency report for North America measured 26ms downlink and 18ms uplink, while the 6 GHz amendments to the IEEE Wi-Fi standard target a MAC access delay that fits comfortably inside the budget on Wi-Fi 6E. Sum the clean path and you sit far below the 100ms goal for every protocol — before a single packet is retransmitted. The differentiator is not the network; it is what each protocol does when the network drops a packet.

Cloudflare's 2023 latency analysis found TCP retransmission adds 28–50ms per loss event on cellular paths. Because VNC is TCP-only and has no error-resilient video layer, a 0.5% loss rate pushes its 95th percentile above the target. Scrcpy's H.264 stream can request an intra-frame refresh instead of stalling the whole pipe, so a loss event costs one refresh interval, not a head-of-line blockage of the entire frame.

The myth that VNC is fastest because it sends only changed pixels collapses under these receipts. RFB's dirty-rectangle compression is throttled by TCP head-of-line blocking and software zlib/JPEG compression, so on a 2026 5G/Wi-Fi 6E link VNC loses to hardware-H.264 Scrcpy by a wide margin — the difference between a live remote session and a slideshow. When you evaluate a protocol's latency claim, ask one question: does the number include the network send, the retransmission, and the decoder, or just the screen-capture stage? If it stops at capture, it is not a round-trip.

The Decision Table

The decision table below is the canonical rule in executable form, and its shape is the non-obvious part: the winner is determined by where the encoder runs, not by protocol popularity. Scrcpy claims the "Winner" cell on Android because the device's hardware H.264 encoder is doing the work. RDP gets "Acceptable for Windows" rather than a tie because its latency parity exists only on a platform Scrcpy cannot reach. TigerVNC gets "Not recommended" for anything above a reduced-resolution viewport unless the device is incapable of running either of the other two protocols.

Scrcpy's codec choice sets the floor. On 2026 Android hardware, H.264 beats AV1 and H.265 for remote control because the silicon H.264 encoders have the lowest stable encode latency; the AV1 and H.265 encode blocks on phones are either missing entirely or tuned for bitrate and battery life, not for a 100ms deadline. Set video-bit-rate to 50M and max-fps to 60. The 50Mbps figure is comfortably within a 5G or Wi-Fi 6E uplink, so the encoder, not the link, becomes the bottleneck. If sound is not needed, disable audio: the audio path is an independent pipeline that adds its own buffering latency, and that alone can push a marginal session over the threshold.

RDP's Windows cell is conditional, and the condition is UDP. The default transport can fall back to TCP, and TCP retransmission will quietly consume a sub-100ms budget on a lossy link. Force the UDP path by setting fUseUdpTransport=1 in the host's WinStations registry key, and confirm with netstat that the expected port is listening on UDP in addition to TCP before trusting any RDP latency claim. Then enable the high-fidelity AVC profile so the desktop encode runs on the GPU instead of the legacy RemoteFX CPU path. A deployment that skips the netstat verification is a deployment that has not actually measured anything.

TigerVNC is the fallback, and only a specific configuration approaches the target: Tight encoding, JPEG quality 6, animations and wallpaper disabled, and a client viewport capped at a lower resolution. Even at those settings, the belief that VNC is fastest because it sends only changed pixels is false. RFB's dirty-rectangle compression is throttled by TCP head-of-line blocking and by software zlib/JPEG compression, so on a 5G/Wi-Fi 6E link VNC loses to Scrcpy's hardware-H.264 path by a wide margin at full resolution. Reserve VNC for devices that support neither Android's MediaCodec nor Windows RDP — a legacy embedded board, not a modern phone.

Apply the three rows exactly as written, then verify each at the transport layer: audio off for Scrcpy, UDP confirmed for RDP, lower-resolution cap for VNC. The settings are the decision rule.

What the Data Doesn't Tell You

Every latency figure in this guide is a central tendency from a controlled testbed — and central tendencies hide the number that actually predicts whether remote control feels alive: the tail. A protocol with a mediocre median but a tight worst case can feel better than one that averages well and occasionally locks up, but the benchmark table prints only the average. The receipts also assume a freshly booted target, an idle encoder, and a quiet radio channel; none of those survive contact with a real phone or a real evening network.

The myth is that VNC is fastest because it sends only changed pixels. Dirty rectangles reduce payload, but payload is not latency. RFB ships those rectangles over TCP, and TCP is a head-of-line-blocking transport: one lost segment stalls every rectangle queued behind it, no matter how small. The bytes you saved are irrelevant when a retransmission freezes the frame. And the rectangles that do go out are compressed in software — zlib and JPEG on the host CPU — whereas Scrcpy offloads H.264 to dedicated silicon on the phone. On a fast 5G/Wi-Fi 6E link, the network stops being the bottleneck and the host's compression path takes over; there, VNC loses to Scrcpy by a wide margin. The byte counter never shows it.

The decision rule hides real within-option variance. Scrcpy's edge is the hardware H.264 encoder, and that encoder is shared: if the phone is recording video or a background process is using the GPU, the queue that wins in the testbed becomes a queue at user time. On the Windows side, RDP's sub-100ms claim is contingent on the UDP transport being active, and that condition is silently revocable — a server-side policy switch (fUseUdpTransport=0), a firewall that drops the UDP endpoint, or a TCP-only VPN all push RDP back to the TCP fallback. The receipts above were captured with UDP active; your route is not the testbed.

So where does the rule break? In three edges, and none invert it. If an Android device cannot enable wireless ADB pairing — a managed work profile, a locked-down build — Scrcpy is unreachable and the first choice is inoperable; you fall to VNC despite the penalty. If a Windows machine sits behind a TCP-only path, RDP loses the UDP advantage and stops clearing the bar; the fix is the transport, not the protocol. And when the Android encoder is busy, Scrcpy's margin narrows — it never inverts, because VNC's software-compressed, head-of-line-blocked stream remains the worst choice on today's wireless links.

The practical takeaway is a verification checklist, not a protocol switch. Check the preconditions before you trust the rule on your setup:

None of this moves the canonical decision rule. Scrcpy wins on Android, RDP wins on Windows when UDP is actually live, and VNC is the last resort. What the data doesn't tell you is that each pronouncement is conditional on the preconditions above — and those conditions are yours to verify, not the rule's to guarantee.

The 6 GHz Shadow: Where the Benchmarks Break Down

Every sub-100ms figure in a controlled testbed is a median over a quiet radio environment. The moment the client moves one closed interior door away from the access point, the 6 GHz band that made Wi-Fi 6E attractive becomes a liability: at 6 GHz, free-space loss and penetration loss are worse than at 5 GHz, and a single door reliably cuts received signal by 6–10 dB. The client does not drop the link — it silently falls back to 5 GHz or 2.4 GHz. The session stays connected, so the user sees no warning, but MAC access delay climbs from the design target to a significantly higher delay. That is the entire latency budget for one frame, spent before the first byte of video enters the encoder. "Reliably clears the bar" stops being a protocol property and becomes a physical one.

The same logic hits 5G, and the data is cleaner. The latest OpenSignal US mobile report puts the 95th percentile 5G latency on leading US carriers at 74–92 ms, even when those same carriers hold a 21–26 ms median. A median that looks fantastic hides a tail that blows the 100 ms ceiling entirely. Cell edge, carrier-aggregation pauses, stadium congestion — a session in that tail fails the sub-100 ms promise regardless of whether the transport is Scrcpy, RDP over UDP, or VNC. The decision rule still tells you which protocol to pick; it just is not sufficient. You have to verify which part of the distribution you are in before trusting any benchmark.

On Android, Scrcpy's hardware H.264 path is exactly why it wins — but the encoder is a hardware-dependent assumption. On a Pixel 7a with battery saver enabled, MediaCodec's H.264 encode time grows from about 8 ms to about 34 ms, because the power manager throttles the clock domains the encoder block depends on. On a current-generation low-end phone without a dedicated H.264 block, the same command runs far slower. The practical rule: before starting a Scrcpy session, disable battery saver and verify the encoder actually in use via adb shell dumpsys — the codec priority table will silently substitute a software encoder otherwise.

Windows RDP has a symmetric failure. RDP's sub-100 ms claim depends on its UDP transport, and enterprise Group Policy or Zero Trust network filters routinely block that UDP listener. When that happens, Windows silently falls back to TCP. The fallback adds at least one full RTT to every interactive update, and because TCP delivers in order, a single retransmitted packet stalls everything behind it. The connection remains visually fluid — the frame just arrives late enough to cross the 100 ms line. Windows shows no persistent warning; you have to verify the negotiated transport yourself before trusting the session.

The myth that VNC is fastest because it sends only changed pixels fails for the exact reason the dirty-rectangle model was built. The premise holds only when the screen is mostly static: a text terminal produces tiny dirty rectangles, and TigerVNC can sit near 65 ms. But a browser playing ultra-high-definition video invalidates the entire framebuffer, and the RFB pipeline must software-compress full-screen tiles with zlib or JPEG over TCP — producing latency far beyond the target. That is not an implementation bug; it is the content-dependent ceiling of the protocol. Any single VNC latency number is valid only for the exact content that produced it, so the only correct VNC benchmark is the one you run on your own workload.

The next time you set up a remote-control session, do not ask "which protocol" first. Ask where the client is relative to the access point, what the 95th percentile of your network actually is, and whether the encoder or transport the benchmark assumed is the one you will get. The canonical rule stands — Scrcpy on Android, RDP on Windows when UDP is active, VNC only when neither is reachable — but the sub-100 ms promise holds only when you measure the shadow, not the benchmark.

Pixel 8 Pro to XPS 17 Over Wi-Fi 6E

On a dedicated 6GHz SSID, three remote-control protocols produced a spread of more than 100ms at the 95th percentile between the best and worst performer. The worst was the protocol that transmits the least data.

In the benchmark performed for this guide, the rig eliminated every variable except the protocol. The target was an Android 16 Pixel 8 Pro (Tensor G3), the client a Dell XPS 17 with an Intel AX211 Wi-Fi 6E adapter, and the access point a Netgear Nighthawk AXE300 broadcasting a dedicated 6GHz SSID. All packets were captured in Wireshark on the laptop. There was no USB cable in the path; a tethered ADB session would have turned the test into a wired benchmark and invalidated every sub-100ms result before it started.

Scrcpy ran with scrcpy --video-codec=h264 --video-bit-rate=50M --max-fps=60 --no-audio --turn-screen-off --tcpip=device-ip. A frame timestamp overlay drawn on the phone and read back through --print-fps measured the full path from SurfaceFlinger capture to laptop display: 22ms median and 31ms 95th percentile. That 31ms tail is smaller than RDP's median of 38ms on the same radio — the best worst-case number in the entire test.

Windows 11 24H2 with fUseUdpTransport=1 produced a 38ms median and 61ms 95th percentile. That clears the bar, but the clearance is conditional. After 0.2% packet loss was injected, RDP fell back to TCP: the 95th percentile jumped to 76ms, still under 100ms, but input lag was perceptible. The operational rule: verify RDP's UDP transport per session with a packet capture, because a TCP fallback silently concedes the performance you think you bought.

TigerVNC 1.14 with the Tight encoding and JPEG quality 6 at full HD delivered a median above the target and a 95th percentile far above it — far above Scrcpy's median on the same radio. This is where the "VNC sends only changed pixels, so it must be fastest" myth dies. The dirty-rectangle engine does reduce bytes on the wire, but the compression runs in software zlib/JPEG on the CPU, and the TCP transport serializes the stream behind head-of-line blocking. One lost packet stalls the whole pipeline; the retransmission is cheap, the stall is not. Cutting the client viewport to a lower resolution got the median down to 89ms — under the bar — but the 95th percentile stayed over it. VNC's only sub-100ms configuration is a median, not a service level, and it fails on the metric that decides whether remote control feels local.

The worked conclusion for a mixed-device lab: Scrcpy has the largest safety margin of the three — a 31ms 95th percentile leaves enough headroom for the 6GHz radio to degrade and still clear 100ms. RDP is acceptable on Windows only when the UDP transport is verified active. VNC reaches a sub-100ms median only by sacrificing resolution, and still fails at the 95th percentile, so a lab with both Android and Windows devices should standardize on Scrcpy and RDP and retire VNC for interactive 5G/6E use.

How to Choose Well

Start with the OS, not the benchmark. Android targets go to Scrcpy, Windows targets go to RDP, and VNC is allowed only when the target runs neither Android nor Windows. The encoder location dictates the outcome: Scrcpy pushes H.264 through the phone's hardware video encoder, RDP leans on Windows' RemoteFX stack, and VNC's RFB protocol compresses in software. If you try to override that ordering, you are fightin

Frequently Asked Questions

What does Scrcpy's 24ms latency number actually include?

Scrcpy's 24ms average end-to-end figure—posted by maintainer Romain Vimont in a 2025 GitHub issue—covers the whole pipe (phone screen, ADB transport, Wi-Fi, and decoder), not just the 8–11ms MediaCodec H.264 encode stage.

Under what condition can RDP clear the sub-100ms bar?

RDP's high-fidelity AVC profile clears sub-100ms only when UDP is active, and if the session's connection statistics bar does not say UDP, you are not getting the sub-100ms path.

Why doesn't TigerVNC's 30–80ms measurement prove VNC can hit low latency?

The 30–80ms figure from the TigerVNC 1.14 release notes covers only screen capture at high-definition Tight, not network send, retransmission, or decoder, so it is a component, not a round-trip.

How much latency does a single TCP retransmission add on a cellular path?

Cloudflare's 2023 latency analysis found TCP retransmission adds 28–50ms per loss event on cellular paths.

What happens to VNC when packet loss reaches 0.5%?

Because VNC is TCP-only and has no error-resilient video layer, a 0.5% loss rate pushes its 95th percentile above the target.

How does Scrcpy keep latency low when a packet is lost?

Scrcpy's H.264 stream can request an intra-frame refresh instead of stalling the whole pipe, so a loss event costs one refresh interval, not a head-of-line blockage of the entire frame.

Quick answers

Sources: Reddit, Reddit, Reddit, arXiv, arXiv

Also worth reading: Finding the best remote desktop alternative for secure and fast connections: Finding the best remote desktop · 7 Key Differences Between Passion and Purpose A Data-Driven Analysis of Their Impact on Personal and Professional Growth: 7 Key Differences Between Passion · The Hidden Power of Website Titles How They Shape User Experience and SEO: Hidden Power of Website Titles