[userbinator]

Lossless encoding can and will consume all available bandwidth available to a client and is designed to be run on local networks.

VNC is unfortunately inherently inefficient because it is just a framebuffer protocol, instead of RDP which passes through the graphics primitives to be rendered. The former will always involve encoding/decoding overhead at the server and client.

[IshKebab]

RDP doesn't pass through graphics primitives. You're probably thinking of X11.

Sending graphics primitives turned out to be the worst way to do remote desktop. All modern solutions just use video codecs. NX (the best solution on Linux) even switched from X11 forwarding to a video codec in NX4.

VNC is inefficient because it is ancient and uses extremely inefficient methods to encode the graphics. GIF is really inefficient too but you wouldn't say that means the idea of encoding animated images as bitmaps is a bad one.

[beagle3]

The original incarnations of RDP, going back 20 years and more, preferred graphics when it could. Back then, it was more bandwidth efficient, and most programs actually used the GDI primitives to draw directly onto the screen, so it actually worked.

But IIRC, by 2007, it switched completely to sending tiles just like VNC.

However, if you read the protocol descriptions, you get the wrong idea that primitives are still used.

Similarly, most X11 clients have been doing everything client side for ages, but many people still believe that peimitives dominate.

[any1]

VNC, the protocol, isn't at all inefficient. There are some encoding methods which are inefficient, but I'd say that more "modern" encoding methods such as "tight" aren't all that bad, depending on how they're implemented. There has also been a recent addition of h264 to some implementations.

An example of a truly inefficient encoding method is ZRLE. It is a tiled zlib and run-length encoded format that can't be split up into multiple jobs because future computation depends on past computation.

They got things right with the tight encoding method of which there are two variants: zlib (lossless) and jpeg. With zlib, you can have up to 4 separate zlib streams, which means that you can utilise 4 CPU cores for encoding in parallel. The jpeg method has no such limitations.

[userbinator]

Yes it does.

https://learn.microsoft.com/en-us/openspecs/windows_protocol...

[vardump]

In the past, maybe Windows XP to perhaps Windows 7 era it did — not sure exactly when they stopped using primitives. But not since a long time. It's just (lossy) compressed bitmap streaming nowadays.

[ComputerGuru]

RDP on Windows from Windows now uses h264 by default.

[layer8]

Interesting. Here is some background: https://techcommunity.microsoft.com/t5/security-compliance-a...

I guess “by default” means if both client and server have the required hardware support and there aren’t too many concurrent sessions.

[any1]

I am pretty sure that no RDP solution for any Linux desktop system uses graphics primitives. For that to happen, all the toolkits would have to implement some way of passing their scene graph and their primitives to the compositor and the compositor would have to know what to do with that info.

RDP also supports plain framebuffers and that's what we use.

Anyhow, with the advent of specialised hardware for video encoding, passing framebuffers isn't necessarily such a bad option. You just have to make sure that the CPU doesn't touch the framebuffer before encoding and after decoding.

[jbverschoor]

Ah the good 'ole days of X11

[notpushkin]

This depends on what your use case is. I think this might be related to gaming uses (e. g. your gaming PC is in another room and you wanna play a game and stream it to your TV or something), although it doesn't seem to be their main priority.